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PRIORITY CLAIM 

This is a continuation of U.S. Patent Application Serial No. 09/191,181, which is a 

A 

continuation of Serial No. 08/656,421 (now Patent No. 5,867,385), which is a 
continuation in part of Serial No. 08/454,7/6^(now Patent No. 5,691,897). 

TECHNICAL FIELD 

The present invention relates to motion control systems and, more particularly, to 
interface software that facilitates the creation of hardware independent motion control 
software that incorporates parameter and/or function access limitations. 

BACKGROUND OF THE INVENTION 

The purpose of a motion control device is to move an object in a desired manner. 
The basic components of a motion control device are a controller and a mechanical 
system. The mechanical system translates signals generated by the controller into 
movement of an object. 

While the mechanical system commonly comprises a drive and an electrical motor, 
a number of other systems, such as hydraulic or vibrational systems, can be used to cause 
movement of an object based on a control signal. Additionally, it is possible for a motion 
control device to comprise a plurality of drives and motors to allow multi-axis control of 
the movement of the object. 

The present invention is of particular importance in the context of a mechanical 
system including at least one drive and electrical motor having a rotating shaft connected 
in some way to the object to be moved, and that application will be described in detail 
herein. But the principles of the present invention are generally applicable to any 
mechanical system that generates movement based on a control signal. The scope of the 




present invention should thus be determined based on the claims appended hereto and not 
the following detailed description. 

In a mechanical system comprising a controller, a drive, and an electrical motor, 
the motor is physically connected to the object to be moved such that rotation of the motor 
shaft is translated into movement of the object. The drive is an electronic power amplifier 
adapted to provide power to a motor to rotate the motor shaft in a controlled manner. 
Based on control commands, the controller controls the drive in a predictable manner such 
that the object is moved in the desired manner. 

These basic components are normally placed into a larger system to accomplish a 
specific task. For example, one controller may operate in conjunction with several drives 
and motors in a multi-axis system for moving a tool along a predetermined path relative to 
a workpiece. 

Additionally, the basic components described above are often used in conjunction 
with a host computer or programmable logic controller (PLC). The host computer or PLC 
allows the use of a high-level programming language to generate control commands that 
are passed to the controller. Software running on the host computer is thus designed to 
simplify the task of programming the controller. 

Companies that manufacture motion control devices are, traditionally, hardware 
oriented companies that manufacture software dedicated to the hardware that they 
manufacture. These software products may be referred to as low level programs. Low 
level programs usually work directly with the motion control command language specific 
to a given motion control device. While such low level programs offer the programmer 
substantially complete control over the hardware, these programs are highly hardware 
dependent. 

In contrast to low-level programs, high-level software programs, referred to 
sometimes as factory automation applications, allow a factory system designer to develop 
application programs that combine large numbers of input/output (I/O) devices, including 
motion control devices, into a complex system used to automate a factory floor 
environment. These factory automation applications allow any number of I/O devices to 
be used in a given system, as long as these devices are supported by the high-level 
program. Custom applications, developed by other software developers, cannot be 
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developed to take advantage of the simple motion control functionality offered by the 
factory automation program. 

Additionally, these programs do not allow the programmer a great degree of 
control over the each motion control device in the system. Each program developed with 
a factory automation application must run within the context of that application. 

In this overall context, a number of different individuals are involved with creating 
a motion control system dedicated to performing a particular task. Usually, these 
individuals have specialized backgrounds that enable them to perform a specific task in 
the overall process of creating a motion control system. The need thus exists for systems 
and methods that facilitate collaboration between individuals of disparate, complimentary 
backgrounds who are cooperating on the development of motion control systems. 



A number of software programs currently exist for programming individual 
motion control devices or for aiding in the development of systems containing a number 
of motion control devices. 

The following is a list of documents disclosing presently commercially available 
high-level software programs: (a) Software Products For Industrial Automation, iconics 
1993; (b) The complete, computer-based automation tool (IGSS), Seven Technologies 
A/S; (c) OpenBatch Product Brief, PID, Inc.; (d) FIX Product Brochure, Intellution 
(1994); (e) Paragon TNT Product Brochure, Intec Controls Corp.; (f) WEB 3.0 Product 
Brochure, Trihedral Engineering Ltd. (1994); and (g) AIM AX- WIN Product Brochure, 
TA Engineering Co., Inc. The following documents disclose simulation software: (a) 
ExperTune PID Tuning Software, Gerry Engineering Software; and (b) XANALOG 
Model NL-SIM Product Brochure, XANALOG. 

The following list identifies documents related to low-level programs: (a) 
Compumotor Digiplan 1993-94 catalog, pages 10-1 1; (b) Aerotech Motion Control 
Product Guide, pages 233-34; (c) PMAC Product Catalog, page 43; (d) PC/DSP-Series 
Motion Controller C Programming Guide, pages 1-3; (e) Oregon Micro Systems Product 
Guide, page 1 7; (f) Precision Microcontrol Product Guide. 
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The Applicants are also aware of a software model referred to as WOSA that has 
been defined by Microsoft for use in the Windows programming environment. The 
WOSA model is discussed in the book Inside Windows 95, on pages 348-351. WOSA is 
also discussed in the paper entitled WOSA Backgrounder: Delivering Enterprise Services 
to the Windows-based Desktop. The WOSA model isolates application programmers 
from the complexities of programming to different service providers by providing an API 
layer that is independent of an underlying hardware or service and an SPI layer that is 
hardware independent but service dependent. The WOSA model has no relation to 
motion control devices. 

The Applicants are also aware of the common programming practice in which 
drivers are provided for hardware such as printers or the like; an application program such 
as a word processor allows a user to select a driver associated with a given printer to 
allow the application program to print on that given printer. 

While this approach does isolates the application programmer from the 
complexities of programming to each hardware configuration in existence, this approach 
does not provide the application programmer with the ability to control the hardware in 
base incremental steps. In the printer example, an application programmer will not be 
able to control each stepper motor in the printer using the provided printer driver; instead, 
the printer driver will control a number of stepper motors in the printer in a predetermined 
sequence as necessary to implement a group of high level commands. 

The software driver model currently used for printers and the like is thus not 
applicable to the development of a sequence of control commands for motion control 
devices. 

The Applicants are additionally aware of application programming interface 
security schemes that are used in general programming to limit access by high-level 
programmers to certain programming variables. For example, Microsoft Corporation's 
Win32 programming environment implements such a security scheme. To the Applicants' 
knowledge, however, no such security scheme has ever been employed in programming 
systems designed to generate software for use in motion control systems. 
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SUMMARY OF THE INVENTION 



The present invention is a system for generating an application program for motion 
control systems including a security system for limiting access to predetermined functions 
5 or parameters of the motion control system. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a systemMnteraction map of a motion control system constructed in 
accordance with, and emboiiying, the principles of the present invention; 

FIG. 2 is a module intVaction map of a motion control component of the system 
shown in FIG. 1 ; 

FIG. 3 is an object interaction map of the component shown in FIG. 2; 
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The present invention is a security system for use with a design system for 
generating application programs for controlling motion control systems. A design system 
in connection with which a security system of the present invention may be used is 
described in U.S. Patent No. 5/ 

Referring now to the drawing, depicted therein at 10 in FIG. 1 is an exemplary 
motion control system capable of incorporating a security system constructed in 
accordance with, and embodying, the principles of the present invention. The principles 
of the present invention may be used with control systems other than the control system 
10 described herein; the following description of control system 10 is thus for illustrative 
purposes only, and any such system that allows the creation of application programs for 
motion control systems can be modified to include a security system of the present 
invention. 

The motion control system 10 comprises a personal computer portion 12 having a 
hardware bus 14, a plurality of motion control hardware controllers 16a, 16b, and 16c, and 
mechanical systems 18a, 18b, and 18c that interact with one or more objects (not shown) 
to be moved. 

The personal computer portion 12 of the system 10 can be any system capable of 
being programmed as described herein, but, in the preferred embodiment, is a system 
capable of running the Microsoft Windows environment. Such a system will normally 
comprise a serial port in addition to the hardware bus 14 shown in FIG. 1. 

The hardware bus 14 provides the physical connections necessary for the computer 
12 to communicate with the hardware controllers 16. The hardware controllers 16 control 
the mechanical system 18 to move in a predictable manner. The mechanical system 18 
comprises a motor or the like the output shaft of which is coupled to the object to be 
moved. The combination of the hardware controllers 16a, 16b, and 16c and the 
mechanical systems 1 8a, 1 8b, and 1 8c forms motion control devices 20a, 20b, and 20c, 
respectively. 
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The hardware bus 14, hardware controllers 16, and mechanical systems 18 are all 
well-known in the art and are discussed herein only to the extent necessary to provide a 
complete understanding of the present invention. 

The personal computer portion 1 2 contains a software system 22 that allows an 
application user 24 to create software applications 26 that control the motion control 
devices 20. 

More particularly, based on data input by the user 24 and the contents of the 
application program 26, the software system 22 generates control commands that are 
transmitted by one or more streams such as those indicated at 28a, 28b, 28c, and 28d. The 
streams 28 transmit control commands incorporating the hardware specific command 
language necessary to control a given motion control device to perform in a desired 
manner. The streams 28 implement the communication protocol that allows the control 
commands to reach the appropriate motion control device 28 via an appropriate channel 
(i.e., PC bus, serial port). 

As discussed above, the method described in this section will normally (but not 
necessarily) involve the labors of at least two and perhaps three separate software 
programmers: a software system designer; a hardware designer familiar with the 
intricacies of the motion control device; and a motion control system designer. The 
application user 24 discussed above will normally be the motion control system designer, 
and the roles of the software system designer and hardware designer will become apparent 
from the following discussion. 

The software system designer develops the software system 22. The software 
system designer initially defines a set of motion control operations that are used to 
perform motion control. The motion control operations are not specifically related to any 
particular motion control device hardware configuration, but are instead abstract 
operations that all motion control device hardware configurations must perform in order 
to ftinction. 

Motion control operations may either be primitive operations or non-primitive 
operations. Primitive operations are operations that are necessary for motion control and 
cannot be simulated using a combination of other motion control operations. Examples of 
primitive operations include GET POSITION and MOVE RELATIVE, which are 




necessary for motion control and cannot be emulated using other motion control 
operations. Non-primitive operations are motion control operations that do not meet the 
definition of a primitive operations. Examples of non-primitive operations include 
CONTOUR MOVE, which may be emulated using a combination of primitive motion 
5 control operations. 

Given the set of motion control operations as defined above, the software system 
designer next defines a service provider interface (SPI) comprising a number of driver 
functions. Driver fiinctions may be either core driver functions or extended driver 
functions. Core driver functions are associated with primitive operations, while extended 
10 driver functions are associated with non-primitive operations. As with motion control 

operations, driver fiinctions are not related to a specific hardware configuration; basically, 
the driver fiinctions define parameters necessary to implement motion control operations 
in a generic sense, but do not attach specific values or the like to these parameters. The 
SPI for the exemplary software system 22 is attached hereto as Appendix A. Ajpf^&tKCS A- H 
\A 15 The software system designer next defines an application programming interface 

~ (API) comprising a set of component functions. For these component fiinctions, the 

\^ software system designer writes component code that associates at least some of the 

hi 

■i" component fiinctions with at least some of the driver functions. The relationship between 

|i component functions and driver functions need not be one to one: for example, certain 

S- 20 component functions are provided for administrative purposes and do not have a 

corresponding driver function. However, most component functions will have an 

associated driver function. The API for the exemplary software system 22 is attached 

hereto as Appendix B. 

The overall software model implemented by the software program 22 thus 
25 contains an API comprising component functions and an SPI comprising driver functions, 

with the API being related to the SPI by component code associated with the component 

functions. 

In order for the system 22 to generate the control commands, at least two more 
components are needed: the application program 26 and at least one software driver such 
30 as the drivers indicated at 30a, 30b, and 30c in FIG. 1. 
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The software drivers 30 are normally developed by a hardware designer and are 
each associated with a single motion control device. The hardware designer writes driver 
code that dictates how to generate control commands for controlling the motion control 
device associated therewith to perform the motion control operations associated with at 
least some of the driver functions. 

In the exemplary software system 22, the software drivers 30a, 30b, and 30c are 
associated with the motion control devices 20a, 20b, and 20c, respectively. As a software 
driver exists for each of the motion control devices 20a, 20b, and 20c, these devices 20a, 
20b, and 20c form a group of supported motion control devices. 

A careful review of the framework of the software system 22 as described above 
will illustrate that, of all the components of this system 22, only the software drivers 30 
are hardware dependent. 

The motion control system designer, normally also the user 24, develops the 
application program 26. The application program 26 comprises a sequence of component 
functions arranged to define the motion control operations necessary to control a motion 
control device to move an object in a desired manner. The application program 26 is any 
application that uses the system 22 by programming the motion control component 35. 
Applications may program the system 22 either through OLE Automation or by using any 
of the custom OLE interfaces making up the APL 

As mentioned above, the component code associates many of the component 
functions with the driver functions, and the driver functions define the parameters 
necessary to carry out the motion control operations. Thus, with appropriately ordered 
component functions, the application program 26 contains the logic necessary to move the 
object in the desired manner. 

Once the application program 26 has been written and the software drivers 30 have 
been provided, the user 24 selects at least one motion control device from the group of 
supported motion control devices 20a, 20b, and 20c. Using a driver administrator module 
32, the user 24 then selects the software driver associated with the selected motion control 
device. This driver administrator module 32 is used to install, uninstall, register, and setup 
each stream. 
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As currently implemented, the driver administrator 32 allows only one software 
driver to be selected. In future versions of the software system 22, the driver 
administrator will allow the user to select one or more software drivers. 

The software system 22 thus generates control commands based on the component 
functions contained in the application program 26, the component code associated with 
the component functions, and the driver code associated with the selected software driver 



As the control commands are being generated as described above, they may be 
directly transmitted to a motion control device to control this device in real time or stored 
in an output file for later use. The software system 22 employs the streams 28 to handle 
the transmission of the control commands to a desired destination thereof. 

In the exemplary system 22, the destinations of the control commands may be one 
or more of an output file 34 and/or the controllers 16. Other possible destinations include 
a debug monitor or window or other custom output mechanism defined for a specific 
situation. The software system designer, or in some cases the hardware system designer, 
will write transmit stream code for each stream 28 that determines how the control 
commands are to be transferred to a given one of the control command destinations 16 
and 34. Using the driver administrator 32, the user 24 selects one or more of the control 
command destinations 16 and 34, and, later when run, the system 22 transfers the control 
commands to the selected control command destination 16 and/or 34 based on the 
transmit stream code in the stream 28 associated with the selected control command 
destination 16 and/or 34. 

Many control command destinations such as 16 and 34 are capable of transmitting 
data back to the system 22. Data transmitted from a control command destination back to 
the system 22 will be referred to as response data. The software system designer thus 
further writes data response stream code for each of the streams 28a, 28b, and 28c that 
determines how response data is transmitted from the controllers 16 to the system 22. The 
system 22 thus processes the response data sent by the controllers 16 based on the data 
response stream code contained in the streams 28. 

Referring again to FIG. 1, this Figure shows that the system 22 ftirther comprises a 
motion control component 35 and a driver stub module 36. The motion control 
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component module 35 is the portion of the software system 22 that relates the component 
functions to the driver functions. The motion control component module 35 thus contains 
the component code that makes the association between the component functions 
contained in the application program 26 and the driver functions. 

The driver stub module 36 is not required to implement the basic software model 
implemented by the system 22, but provides the system 22 with significantly greater 
flexibility to accommodate diverse motion control hardware configurations with minimal 



More particularly, when the driver stub module 36 is employed, the hardware 
designer need not develop driver code to implement all of the driver functions; to the 
contrary, the hardware designer must write driver code for implementing the core driver 
functions but need not write driver code to implement the extended driver functions. The 
software system designer provides the motion control driver stub 36 with stub code that 
identifies the combinations of core driver functions that are employed to emulate the 
functionality of extended driver functions. 

The motion control component 24 will determine for the selected software driver 
30 which extended functions, if any, the selected driver 30 supports. For extended 
functions that are not supported, referred to herein as non-supported extended driver 
functions, the motion control component 35 refers to the driver stub module 36 to 
determine the appropriate combination of core driver functions to emulate the 
functionality of the non-supported extended driver functions. The system 22 thus 
generates the control commands necessary to implement the non-supported extended 
driver functions using the appropriate combination of core driver functions. 

The process of determining when extended driver functions need to be emulated 
can be optimized by providing the motion control component 35 with a function pointer 
table that contains a pointer to each of extended functions. When building the function 
pointer table, the motion control component 35 checks the selected driver module 30 to 
see if it supports each extended function. If the selected driver module 30 supports the 
extended function, the motion control component module 35 stores a pointer to the 
function, implemented by the selected driver module 30, in the table location 
corresponding to the extended function. In the event that the selected driver module 30 
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does not support the extended function, the motion control component module 35 stores a 
pointer to the extended function implementation located in the driver stub module 36. 
The driver stub module 36 implementation of the extended function contains calls to a 
plurality of core functions implemented by the selected driver module 30, 

Therefore, the driver stub module 36 allows the motion control system designer to 
use, with minimal time and effort by the hardware designer, a working software driver 28 
that contains driver code to implement only the core functions. The software driver 28 
developed to implement the core driver functions can then be improved by developing 
driver code to implement extended driver functions as desired. 

The use of driver code specifically designed to implement extended driver 
functions is, in general, preferable to relying on the driver stub module 36 to emulate the 
extended driver functions; driver code specifically written to implement an extended 
driver function will almost always obtain a more optimized implementation of the driver 
function than the emulation of that driver function with a combination of core driver 
functions. 

Referring again for a moment to FIG. 1, this Figure illustrates that the system 22 
additionally comprises a driver administrator CPL applet 38 and a DDE server 40. The 
driver administration CPL applet 38 generates the user interface through which the user 
24 communicates with the driver administrator module 32. The DDE server 40 provides 
the software interface through which the application program 26 communicates with the 
motion control component module 35. 



The motion control component 35 will now be described in fiirther detail with 
reference to FIGS. 2-10. The motion control component 35 is used by every application 
programming the system 22 to perform motion control operations. The major set of the 
API is implemented by this component. When operating, the motion control component 
35 interacts with the driver administrator 32, to get the current driver, and the driver 30 
and driver stub 36, to carry out motion control operations. Applications, using system 22, 
only interact with the motion control component 35, 
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This section describes the design of the motion control component 35 in three 
main parts. First, all binary modules that affect the component 35 are described along 
with their interactions with the component 35. Next, the module interaction-map is drawn 
in more detail to show the interactions between all C++ objects used to implement the 
motion control component 35. Next, the object interaction-map is tested by displaying the 
specific interactions that take place during certain, key process that the component 35 is 
requested to perform. 

The module interaction-map shown in FIG. 2 displays all binary modules and their 
interactions with the motion control component 35. As can be seen from the module 
interaction-map, applications only communicate with the motion control component 35. 
From this point, the component 35 coordinates all interactions between the driver 
administrator 32, driver 30, and driver stub 36 components. 

Breaking the module interaction-map and adding the interactions taking place 
between all C++ objects used to implement the motion control component 35, produces 
the object interaction-map shown in FIG. 3. 

Each object in the diagram is described as follows. The CCmpntDisp object is the 
dispatch object used to dispatch exposed interface methods. During the dispatch process, 
all raw data is converted into the appropriate C++ form. For example, collections of data 
passed between OLE components is usually packaged in a raw block of memory. The 
CCmpntDisp object takes care of packing outgoing data and unpacking incoming data. 
Data packing involves converting the data between a raw and native C++ format. 

The CDriverAdmin object is used to communicate directly with the driver 
administrator component. All OLE related details are encapsulated within this class. 

The CDriverMgr object is used to control all unit mapping taking place before 
calling the appropriate Driver function. The CUnitMapper object is used to do the actual 
mapping between units. 

The CUnitMapper object is used to map units between the Part Coordinate System 
(PCS) and the Machine Coordinate System (MCS). Both directions of unit mapping are 
done by this object. 

The CDriver object is used to build the SPI table containing both core and 
extended Driver functions. Depending on the level of driver support, the extended 
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functions in the SPI table may point to functions implemented in either the driver stub 36 
or the driver 30. 

The following discussion of FIGS 4-8 describes all main scenarios, or operations, 
that occur on the motion control component 35. Each scenario-map displays all objects 
involved, and the interactions that take place between them in the sequence that they 
occur. 

As shown in FIG. 4, before an application can use the motion control component 
35, it must create an instance of the object, using the CoCreatelnstance OLE function, and 
then initialize the instance calling the exposed Initialize custom interface method 
implemented by the component 35. FIG. 4 displays the sequence of events that take place 
when the Initialize method is called. 

During initialization, the following steps occur. First the application must create 
an instance of the motion control component 35 by calling the standard OLE function 
CoCreatelnstance. Once loaded, the application must call the component 35's exposed 
Initialize method. When first loaded, the component 35 loads any registration data 
previously stored. Next, the component 35 directs the CCmpntDisp to initialize the 
system. The CCmpntDisp directs the CDriverAdmin to get the current driver(s) to use. 
The CDriverAdmin, first, loads the driver administrator 32 using the standard OLE 
CoCreatelnstance function. Next, it initializes the driver administrator. Then, it queries 
the driver administrator for the driver(s) to use and their SPI support information. Finally, 
the driver administrator returns the driver(s) and the support information to the component 
35, and releases all interfaces used from the driver administrator component 32. 

Once receiving the active driver(s) 30 and their support information, the motion 
control component 35 passes the driver(s) 30 to the CDriverMgr and directs it to initialize 
the system. During its initialization, the CDriverMgr initializes the CUnitMapper. Also 
while initializing, the CDriverMgr initializes a CDriver for each driver used. After 
initializing each CDriver, the support information is used to build each SPI table inside 
each CDriver object. When building the SPI table, all core and supported extended SPI 
interfaces are queried from the driver. Also, when building the SPI table, the CDriver 
queries all interfaces, not supported by the driver 30, from the driver stub 36. 
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Referring now to FIG. 5, once the motion control component 35 is initialized, the 
application 26 may perform operations on it. There are two types of operations that may 
take place on the component 35: Operations that use core Driver functions, and 
operations that use extended Driver functions. Even though the difference between the 
two is completely invisible to the application using the component 35, the internal 
interactions are different between the two. The following discussion outline these 
differences. 

The following interactions take place when the component 35 performs an 
operation that uses core Driver functions only. First the application must request the 
operation and pass all pertinent parameters to the component 35. Next, the component 35 
directs the CCmpntDisp to carry out the operation. The CCmpntDisp then directs the 
CDriverMgr to perform the operation and passes all pertinent parameters to it. Before 
carrying out the operation, the CDriverMgr uses the CUnitMapper to convert all units to 
the Machine Coordinate System (MCS). Next, the CDriverMgr directs the CDriver object 
to carry out the operation and passes the newly mapped parameters to it. The CDriver 
object uses its internal SPI table to communicate directly with the core Driver function 
implemented by the driver component. 

FIG. 6 shows the sequence of events that occurs when the component 35 is 
directed to carry out an operation that happens to use extended SPI not supported by the 
driver 30. The following steps occur when the operation is requested. 

First the application must request the operation and pass all pertinent parameters to 
the component 35. Next, the component 35 directs the CCmpntDisp to carry out the 
operation. The CCmpntDisp then directs the CDriverMgr to perform the operation and 
passes all pertinent parameters to it. Before carrying out the operation, the CDriverMgr 
uses the CUnitMapper to convert all units to the Machine Coordinate System (MCS). 
Next, the CDriverMgr directs the CDriver object to carry out the operation and passes the 
newly mapped parameters to it. The CDriver object uses its internal SPI table to 
communicate directly with the core Driver function implemented by the driver 
component. 

As briefly discussed above, when using the system 22, there are several types of 
units and two different coordinate systems used. The process of unit mapping involves 
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converting measurements between the Part and Machine coordinate systems. FIG. 7 
illustrates this process, and the following steps occur when the operation is requested. 

First the application must request the operation and pass all parameters to the 
component 35. Note, all parameters are in the PCS. Next, the component 35 directs the 
CCmpntDisp to carry out the operation. The CCmpntDisp directs the CDriverMgr to 
carry out the operation and passes the PCS parameters to it. The CDriverMgr takes all 
measurements and uses the CUnitMapper to convert them to the MCS. The newly 
mapped parameters are then passed to the Cdriver. The CDriver directs either the driver 
or the driver stub component to carry out the operation. 

When the application is finished using the motion control component 35 it directs 
the component 35 to fi-ee all of its resources by calling its exposed Release method. This 
process is depicted in FIG. 8. During the clean-up process, the following steps occur. 

First the application must direct the component 35 to release all of its resources by 
calling its Release method. When invoked, the component 35 passes the call on to the 
CCmpntDisp object. The CCmpntDisp object directs the CDriverMgr to release any 
resources it is using. The CDriverMgr directs each CDriver object to release any of its 
resources, then deletes the CDriver objects. First, the CDriver object releases any 
interfaces it is using from the driver component. Then, the CDriver object releases any 
interfaces it is using from the driver stub component. 

FIG. 9 is an interface map related to the motion control component 35. FIG. 10 is 
a data map showing how data relating to the whether extended driver functions need to be 
emulated is stored. Attached hereto as Appendix C is a document that describes the actual 
OLE Interfaces exposed, the definitions of the data structures used when passing data 
around, and the definitions of each class used internally by the motion control component 



The driver 30 is used by both the driver administrator 32 and the component 35. 
Its main purpose is to implement fiinctionality that generates motion control commands 
for the specific hardware supported. For example, the AT6400 driver, used to control the 
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Compumotor AT6400 motion control hardware, generates AT6400 command codes. 
During the initialization phase of the system 22, the driver administrator 32 communicates 
with each driver 30, allowing the user to add, remove, or change the configuration of the 
driver. When an application, using the system 22, is run, the component 35 communicates 
with the driver 30 directing it to carry out the appropriate motion control operations. 

This section describes the complete design of a generic driver 30. All drivers are 
designed from the base design described in this manual. This section is divided into three 
parts. First, a module interaction-map that describes all binary modules that interact with 
the driver 30 is discussed. Next, the module interaction-map is drawn as an object 
interaction-map, where all the internals of the driver are exposed. In this map, all C-H- 
objects, making up the driver, and their interactions are shown. Next, several scenario- 
maps are drawn. Each scenario-map displays the interactions taking place between the 
C-H- objects involved during a certain process. Finally, this section describes the 
interfaces exposed by the driver component, all data structures used, and the definitions of 
each C++ class used. 

Referring now to FIG. 1 1, the module interaction-map displays 'all binary modules 
and their interactions with the driver 30. There are two modules that interact directly with 
the driver: the motion control component 35, and the driver administrator 32. The driver 
administrator 32 queries and changes the driver settings and the component 35 directs the 
driver to carry out motion control operations, such as moving to a certain location in the 
system. Shown at 42 in FIG. 1 1 is the standard Windows registration database, referred to 
herein as the registry. 

Breaking the module interaction-map down into more detail by including the 
interactions taking place between all C++ objects used to implement the driver, produces 
the object interaction-map. The object interaction-map for the driver 30 is shown in FIG. 



Each object in the diagram is described as follows. 

CDriverDisp is the dispatch object used to dispatch exposed interface methods. 
During the dispatch process, all raw data is converted into the appropriate C++ form. For 
example, collections of data passed between OLE components is usually packaged in a 
raw block of memory. The CDriverDisp object takes care of packing outgoing data and 
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unpacking incoming data. Data packing involves converting the data between a raw and 
native C++ format. 

The CStreamMgr object is responsible for managing the set of streams registered 
with the driver. Streams, may be added, removed, and enabled. Only enabled streams are 
sent data. The CLSID and enabled status of each stream registered, is stored in the 
registration database. When communicating to streams, the CStreamMgr is used to send 
the command string to all enabled streams. 

The CCommandMgr object is used to build commands sent to the stream, and 
extracting responses received from the stream. The CCommandMgr is the controlling 
object that manages the CResponse, CCommandList, and CStream objects. 

The CCommandList object stores the complete list of commands making up the 
motion control command language. Such commands may be stored as text resources or in 
a text file. 

The CCommand object builds command strings that are then sent to the CStream. 
Each command built is a complete motion control command string. 

The CResponseList object builds CResponse objects that are initialized with the 
parsing format for the expected response. 

The CResponse object converts raw response strings, returned by the CStream, 
and converts them into C++ data types. For example, a response string containing 
position data may be converted into a set of double values. 

The CStream object is used to communicate directly with the underlying stream 
component. 

Figures 14-20 contain scenario maps that describe all main scenarios, or 
operations, that occur on the driver 30. Each scenario-map displays all objects involved, 
and the interactions that take place between them in the sequence that they occur. 

There are two types of operations that occur on the driver 30. First, the driver 
administrator 32 may initiate operations, such as adding streams or configuring the driver. 
Next, the motion control component 35 may initiate operations on the driver when an 
application is actually running. The following discussion describes each perspective, 
starting with the operations directed by the Driver Administrator; all operations made on 



the driver by the driver administrator are discussed in the order that they may occur when 
using the driver. 

Before a driver may be used, it must be registered in the OLE system. In order to 
register a driver the driver administrator first verifies that the module being registered is 
actually an driver 30, then it calls the DLLRegisterServer exported function to register the 
driver. Each module of the system 22 exports a function called DLLGetModuleType. 
This function is used to verify that the module is an driver 30 component. FIG. 13 
displays the interactions that take place when registering a driver. 

During the registration process shown in FIG. 13, the following steps occur. First, 
the driver administrator must load the DLL, containing the stream component, verify that 
the module is an driver 30. To do so, the driver administrator calls the 
DLLGetModuleType function, exported by the driver. If the function returns a value that 
contains the value XMC_DRIVER_MT in the high byte, then the driver administrator 
proceeds and registers the driver by calling its exported function, DLLRegisterServer. 
When called, the implementation of the DLLRegisterServer writes all OLE 2.0 
registration information to the Windows registration database. 

Referring now to Figure 14, after the driver is registered, the driver administrator 
can load the component 35 using the OLE CoCreatelnstance function. During the 
initialization process, the driver loads all registration data and initializes both the 
CDriverDisp and CStreamMgr C++ objects. 

During initialization, the following steps occur. 

Before loading the driver component, the driver administrator must query the 
driver module for its CLSID. Calling the driver's exported function, DLLGetCLSID, 
returns the CLSID, Once it has the CLSID, the driver administrator may create an 
instance of the driver by calling the standard OLE function CoCreatelnstance. When first 
loaded, the driver loads any registration data previously stored. Next, the driver directs 
the CDriverDisp object to initialize the system. When notified, the CDriverDisp object 
initializes itself and then directs the CStreamMgr to initialize itself During its 
initialization, the CStreamMgr loads all stream settings from the registration database. 
For example, the CLSID and enabled state of all streams previously registered with the 
driver, are loaded. 

TO 




After initializing the driver, the driver administrator may perform operations on it. 
For example, the driver administrator may request the driver to add or remove a stream. 
FIG. 15 displays the sequence of events occurring when the driver is requested to add a 
new stream. When adding a stream, the following steps occur. 
5 First the driver administrator directs the stream to add a new stream and passes 

CLSID of the stream, to be added, to the driver. The driver then passes the CLSID to the 
CDriverDisp object and directs it to add the stream. The CDriverDisp object passes the 
information on to the CStreamMgr and directs it to add the stream. In the final step, the 
CStreamMgr assumes that the module is a valid stream component 28 and adds the 
10 CLSID to the drivers set of information in the registration database. 

Another operation requested of the driver, after initialization, is that of querying it 
for its current settings. Before displaying information about the driver, like the name of 
the hardware it supports, the driver administrator must query the driver for the 
£ information. For example, FIG. 16 displays the process of querying the driver for an 

W 15 enumeration of the streams registered with it. When querying the driver for information, 

the following steps occur, 
j^; First the driver administrator, calls the interface method used to query the driver's 

=i stream enumeration. Next, the driver directs the CDriverDisp to create the stream 

i5 enumeration. The CDriverDisp object then directs the CStreamMgr to prepare the stream 

;~ 20 enumeration. The CStreamMgr checks the registration database and makes sure its 
□ internal state is in sync with the data stored in the registry. Next, it sets a lock that will 

~ cause all stream management operations, such as adding or removing streams, to fail. The 

CStreamMgr prepares the list of streams and loads them into memory using the CStream 
object. The CStream object loads the stream component using the OLE CoCreatelnstance 
25 API. 

After the driver administrator is done using the driver, it must release the driver by 
calling its exposed Release method. Calling this method, directs the driver to release all 
resources used. FIG. 17 displays the process of releasing the driver component. During 
the clean-up process, the following steps occur. 
30 First the driver administrator must direct the driver component to clean itself up by 

calling its Release method. When invoked, the driver component passes the call on to the 
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CDriverDisp object. The CDriverDisp object then directs the CStreamMgr to save all 
data. The CStreamMgr saves all data, including the state of each stream, in the 
registration database. Finally, the driver saves all internal data in the registration 
database. 

After a driver is successfully installed into the system 22 and configured using the 
driver administrator, it is ready for use by the motion control component 35. The 
component 35 uses the driver 30 when performing motion control operations requested 
from the application using the component 35. The following discussion describes the 
component 35 directed operations that can take place on the driver. 

Before using the driver, it must be initialized by the component 35. This operation 
is different from the driver initialization taking place on the driver when used by the 
driver administrator because the system must be prepared for sending and receiving 
commands. In order to prepare for the data communication, the stream must be initialized 
and then opened. FIG. 18 describes the initialization process. The following steps occur 
during the initialization process. 

First the component 35 must direct the driver to initialize itself This is usually a 
two step process. In the first step, the component 35 creates and instance of the driver 
using the standard OLE CoCreatelnstance function. Next, the Initialize method, exposed 
by the driver, is called to prepare the driver for data transmissions. When the Initialize 
method is called, the driver first loads any internal data stored in the registration database 
42. Next, the driver directs the CDriverDisp to initialize the internal system. The 
CDriverDisp then directs the CStreamMgr to initialize the streams. Next, the 
CStreamMgr loads all data from the registration database, including the set of all CLSID's 
and enabled status' for all streams registered with the driver. Then the CStreamMgr loads 
each enabled stream by creating a new CStream object for each enabled stream. When 
creating each CStream object, the CLSID for the underlying stream is passed to the 
CStream object. When each CStream object is created and attached to a stream 
component it loads the component 35 by calling the standard OLE CoCreatelnstance 
function. Once the CStreamMgr is done, the CDriverDisp directs the CCommandMgr to 
initialize itself During its initialization process, the CCommandMgr initializes and loads 
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the CCommandList. Also, when the CCommandMgr is initializing, it loads the 
CResponseList corresponding to the CCommandList. 

Once the system is initialized, the motion control component 35 can direct the 
driver to carry out certain command operations. Command operations are standard 
motion control operations such as moving to a specific location in the system, or querying 
the system for the current position. FIG. 19 describes the process of commanding the 
driver to carry out a certain operation. When commanding the driver to perform a certain 
operation the following steps occur. 

First, the component 35 directs the driver to perform the operation, such as moving 
to a position or querying the system for the current position. Next, the driver directs the 
CDriverDisp object to perform the operation. The CDriverDisp object then directs the 
CCommandMgr to build the appropriate command. Any parameters related to the 
command are passed to the CCommandMgr. For example, when directing the driver to 
move to a certain position, the position information is passed to the CCommandMgr. 
Next, the CCommandMgr requests the CResponseList to create a CResponse object. The 
CResponseList looks up the response format and uses it to create a new CResponse object 
that is returned to the CCommandMgr. Then, the CCommandMgr directs the 
CCommandList to create the command. Any parameters related to the command are 
passed to the CCommandList. The CCommandList creates a new CCommand object, 
looks up the raw command string, and passes it and the command parameters to the 
CCommand object who then builds the command string. 

The CCommandMgr, then passes the CCommand object, returned by the 
CCommandList, and the previously created CResponse object to the CStreamMgr object. 
The CStreamMgr object is directed to process the objects. The CStreamMgr passes the 
CCommand and CResponse objects to all enabled CStream objects. The CStream object 
queries the CCommand object for the full command string in raw text form. The raw text 
command is passed to the stream component. Next, the CStream object waits for the 
response, then reads the raw text response into a buffer. The raw text response is then 
passed to the CResponse object. Next the CRETONNE object is returned to the 
CStreamMgr, who returns it to the CCommandMgr, who returns it to the CDriverDisp 
object. Eventually the CResponse returns to the CDriverDisp object, who then directs the 





CResponse to convert the response into a generic €++ type. The generic type is returned 
to the motion control component 35. 

Once the component 35 is finished using the driver, the driver must be released by 
calHng its Release method. Releasing the driver frees all resources used by the driver. 
5 FIG. 20 describes the process of releasing the driver. The following steps occur when 
cleaning up and freeing all resources used by the driver. 

First, the component 35 must call the driver's Release method. When called, the 
driver directs the CDriverDisp object to release any resources used. The CDriverDisp 
then directs the CStreamMgr to free any resources used. The CStreamMgr then frees all 
10 active CStream objects. Each CStream object releases all stream component interfaces 
used. Next the CDriverDisp directs the CCommandMgr to free all of its resources. 
During its clean-up, the CCommandMgr frees the CCommandList object. To complete its 
clean-up, the CCommandMgr frees the CResponseList object. 

Attached hereto as Appendix D is a document that describes the actual OLE 
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\n 15 Interfaces exposed, the definitions of the data structures used when passing data around, 
jS and the definitions of each class used internally by the driver. 
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O 20 This section describes the stream component 28 used as the data transport layer 

□ between the driver 30 component and the destination output location such as the motion 

control device 20 and/or the output file 34. For example, when using motion control 
hardware that is connected to the PC Bus, the driver 30 Component will communicate 
with the PC Bus stream component 28. 
25 The design of a stream component 28 will be discussed in three parts. First, a 

Module Interaction-Map describes the modules that are involved, with respect to the 
stream, and how they interact with one another. Next, the Object Interaction-Map breaks 
the Module Interaction-Map down into a more detailed view that not only displays the 
interactions occurring between modules, but also the interactions taking place between the 
30 C++ objects within the stream component 28. Then, the Object Interaction-Map is 
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"tested" by running it through several Scenario-Maps. Each Scenario-Map displays the 
object interactions taking place during a certain operation. 

The Module Interaction-Map shown in FIG. 22 displays all modules that interact 
with the stream component 28. Interactions begin from two different perspectives. First, 
the driver administrator 32 interacts with the stream component 28 when installing, 
removing, and configuring the stream. Next, when used, each driver 30 interacts with the 
stream while sending and retrieving data to and from the destination. For example, when 
a driver writes data to a text file stream, the stream takes care of writing the data out to the 
file. Or, if the driver reads data from a PC Bus stream, the stream does the actual read 
from the hardware and passes the data back to the driver. 

Drivers only communicate with streams that have been specifically connected to 
the driver. Once connected, the stream is used to communicate with the destination 
object, like the PC Bus, serial I/O connection, text file, or debug monitor. 

The stream component 28 shown in FIG. 22 is the object that operates as the data 
transport layer for each driver. Each stream has a different target that defines the type of 
the stream. The following are the current stream targets. 

PC Bus/WinNT - This Windows NT stream uses a Windows NT .SYS 

device driver to communicate directly with the motion control hardware connected 

to the PC Bus. 

PC Bus/Win95 - This Windows 95 stream uses a Windows 95 VxD to 
communicate directly with the motion control hardware connected to the PC Bus. 

PC BusAVin 3.1 - This Windows 3.1 stream communicates directly with 
the motion control hardware connected to the PC Bus. 

Serial - This stream uses the COMM API to communicate with the motion 
control hardware connected to the serial port. 

Text File - This stream is write-only and sends all data to a text file. 

Debug Monitor - This stream is write only and sends all data to the debug 
monitor. 

Custom - This is a custom stream that sends data to an unknown location. 
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Similar to the Module Interaction-Map, the Object Interaction-Map displays 
interactions between modules. In addition, this map, shows all interactions taking place 
between each C-H- object within the stream component 28. FIG. 23 is the Object 
Interaction-Map for the stream component 28. 

Each object in the diagram is described as follows. The CStreamDisp object is the 
dispatch object used to dispatch exposed interface methods. During the dispatch process, 
all raw data is converted into the appropriate C++ form. For example, collections of data 
passed between OLE components is usually packaged in a raw block of memory. The 
CStreamDisp object takes care of packing outgoing data and unpacking incoming data. 
Data packing involves converting the data between a raw and native C++ format. 

The CRegistryMgr object takes care of managing all data stored in the registration 
database. Since many streams of the same type may exist at the same time, each stream is 
assigned a handle. The handle assigned, is used by the stream to look up the location it 
uses to load and store data in the registration database, much as an library index is used to 
locate a library book. 

All input and output is funnelled through the CIOMgr manager. Management of 
input and output operations consists of buffering data and controlling primitives used to 
transport data to and from the target location. 

The CIOHAL object is the input/output hardware abstraction layer. With in this 
object lay all hardware dependent code such as calls to inp and outp. Each different type 
of stream contains a different implementation of this object. 

Scenario-Maps are specialized Object Interaction-Maps that display how each 
module and the objects inside the stream component interact with one another during the 
operation described by the map. The Scenario-Maps in FIGS. 24-32 are broken into two 
different categories; those that are initiated by the driver administrator 32, and those that 
are initiated by the driver 30. 

Operations directed by the driver administrator are usually related to initializing, 
uninitializing, and configuring the stream. The following sections describe all operations, 
directed by the driver administrator, that take place on the stream. 

Before a stream component can be used by anyone, it must be registered in the 
Windows registration database. Registration is a standard OLE 2.0 operation required in 
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order to use any OLE 2.0 component, such as the stream component. FIG. 24 describes 
this process. During the registration process, the following steps occur. 

First, the driver administrator must load the DLL, containing the stream 
component, verify that the module is an stream component 28. To do so, the driver 
administrator calls the DLLGetModuleType function, exported by the stream. If the high 
byte in the return value contains the value XMC_STREAM_MT, then the driver 
administrator proceeds and registers the stream by calling its exported function, 
DLLRegisterServer. When called, the implementation of the DLLRegisterServer writes 
all OLE 2.0 registration information to the Windows registration database. 

After the stream component is successfully registered, it is ready for initialization. 
During initialization, the stream component not only initializes itself, but also initializes 
any device drivers used by registering the driver with the operating system. For example, 
the Windows NT stream component registers the Windows NT .SYS driver with 
Windows NT and starts the service. FIG. 25 describes this process. During initialization, 
the following steps occur. 

First the driver administrator must direct the stream to initialize itself When 
making this call, the name and location of the driver used, and the handle of the stream are 
passed into the method as arguments. Once directed to initialize itself, the stream 
component calls the CStreamDisp and directs it to initialize the system. The 
CStreamDisp object then directs the CRegistryMgr to load all pertinent data for the stream 
using the handle passed to it. The CRegistryMgr loads all data from the registration 
database. After all information is loaded from the registry, the CStreamDisp directs the 
CIQMgr to register the appropriate driver with the operating system. The CIOMgr directs 
the CIOHAL to register the driver, if appropriate. If running in Windows NT, the 
CIOHAL registers the .SYS driver with the Windows NT operating system and starts the 
driver. If running in Windows 95, the VxD integrity is verified with a quick, dynamic, 
load and unload. 

After initializing the stream component, it may be queried for its current settings 
or directed to set new settings. Since both operations are very similar, only changing 
settings will be described. Stream settings include data such as: port addresses, IRQ 
levels, file names, etc. Any data needed to communicate with the output/input target are 
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included in the stream settings. FIG. 26 describes the process of changing the streams 
settings. During the setup process, the following steps occur. 

First the driver administrator directs the stream to use the data passed to change its 
internal data. Once directed, the stream component passes the interface method 
invocation to the CStreamDisp object. The CStreamDisp object then directs the 
CRegistryMgr to store the new settings. The CRegistryMgr stores the new values in the 
registration database. 

When the driver administrator is done using a stream component, it must clean up 
the resources used. FIG. 27 describes this process. During the clean-up process, the 
following steps occur. First the driver administrator must direct the stream component to 
clean itself up by calling its Release method. When invoked, the stream component 
passes the call on to the CStreamDisp object. The CStreamDisp object then directs the 
CRegistryMgr to save all data. All persistent data is saved to the registration database by 
the CRegistryMgr. 

Driver directed operations occur when each driver 30 uses the stream component 
28 connected to it. Remember, each stream component is used as the data transport layer. 
Each driver uses the stream to transfer the motion control command data, it generates, to 
the output target. Streams are also used to transfer data back to the driver when read 
operations occur. Only certain streams are readable. 

Before the driver can perform operations on the stream, the stream must be 
initialized. Initialization occurs in two steps. First the OLE stream component must be 
loaded, and then once it is, the stream must be explicitly initialized. FIG. 28 describes the 
second portion of the initialization process. The following steps occur during the 
initialization process. 

First the driver must invoke the Initialize methods exported by one of the stream 
interfaces. When calling Initialize, the driver passes to the stream, the stream handle. 
Next, the stream passes the directive on to the CStreamDisp object for dispatching. The 
CStreamDisp object first directs the CRegistryMgr to load all settings stored in the 
location defined by the stream handle. The CRegistryMgr reads in the data stored in the 
registry at the handle. After the data is loaded, the CStreamDisp, directs the CIOMgr to 
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initialize itself. As part of its initialization, the CIOMgr initializes the CIOHAL object 
that it is using. 

Once a stream has been initialized, it must be opened. Opening a stream places 
the stream in a state where it can pass data between the driver and the target. FIG. 29 
describes the process of opening a stream. When opening a stream, the following steps 
occur. 

First the driver directs the stream to open itself, by calling the Open exposed 
interface method. Once directed, the stream passes the call on to the CStreamDisp object. 
Next, the CStreamDisp object directs the CIOMgr to open the stream. At this time, the 
CIOMgr prepares any buffers that will later be used when transferring data through the 
stream. After the buffers are ready, the CIOMgr directs the CIOHAL object to interact 
with the target and open it. CIOHAL directly communicates with the target or with a 
device driver and opens the stream. When operating with hardware streams, the device 
driver, or Serial 10 directly communicates with the hardware and prepares it for operation. 

After opening a stream, it is ready to perform data transport operations. There are 
two main data transport operations available: Reading data, and writing data. FIG. 30 
describes the process of writing data to the stream. When writing to the stream, the 
following steps occur. First the driver directs the stream to write data to the target and 
passes the data to the stream. Next, the stream passes the data to the CStreamDisp object. 
The CStreamDisp object passes the block of data to the CIOMgr and directs it to write it 
to the target. The CIOMgr object either passes the complete block of data to the CIOHAL 
object, or stores the block in an internal buffer and then passes pieces of the buffer to the 
CIOHAL object until the complete buffer is sent. The CIOHAL object takes the data 
passed to it and either sends it directly to the target, passes it to a device driver, or calls 
COMM API to send the data to the Serial lO port. The device driver or COMM API 
sends the data directly to the hardware controlled. 

Certain streams, like the PC Bus and Serial 10 streams, return data after write 
operations occur on them. The data returned may be specific to a previous request for 
data, or status describing the success or failure of the previous write operation. FIG. 3 1 
describes the process of reading data from the stream. It should be noted that not all 
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Streams are readable. Currently, the only readable streams are the PC Bus and Serial 
streams. During the operation of reading data from the target, the following steps occur. 

First the driver directs the stream to read data from the target. The stream passes 
the call on to the CStreamDisp object. The CStreamDisp object directs the CIOMgr to 
perform the read. Depending on how the stream is implemented, the CIOMgr may either 
make one call or multiple calls to the CIOHAL object. If multiple calls are made, all data 
read is stored in CIOMgr internal buffers. The CIOHAL object either directly 
communicates to the hardware, uses the COMM API, or a device driver to read the data. 
If a device driver or the COMM API are used, they directly communicate with the 
hardware to read the data. 

Once the driver is done using the stream, it must direct the stream to clean-up all 
resources used. To do so, the driver calls the standard Release method. FIG. 32 displays 
the sequence of events taking place after the Release method is called. The following 
steps occur when cleaning up and freeing all resources used by the stream. 

First the driver must call the stream's Release method. Next, the stream directs the 
CStreamDisp object to release all resources used. The CStreamDisp object then directs 
the CIOMgr to free any resources used in buffers, etc. Next, the CIOMgr directs the 
CIOHAL to free any resources used. During its clean-up and depending on the type of 
stream, the CIOHAL will delete text files used, close the debug monitor, shut-down the 
hardware, or direct any device drivers to shut-down the hardware. If device drivers or the 
COMM API are used, they direct the hardware to shut-down. 

FIG. 33 depicts an interface map for the stream 28. Attached hereto in Appendix 
E is a document that describes the actual OLE Interfaces exposed, the definitions of the 
data structures used when passing data around, and the definitions of each class used 
internally by the stream. 



The driver stub module 36 is used to fill in the extended Driver functions that the 
driver 30 is unable to support or implement. By simulafing the extended SPI, applications 
are able to use a larger set of motion control functionality than would be available if the 
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application directly programmed the motion control hardware. In order to implement the 
extended SPI, the driver stub uses software algorithms that call core SPI interface 
methods implemented by the driver 30. During the initialization of the driver stub, the 
driver 30 to use is registered with the driver stub. 

This section describes all aspects of the driver stub 36 in three basic parts. The 
first part of this section describes all binary modules affecting the driver stub. Next, a 
more detailed view, that includes all C++ objects used inside the driver stub, is described. 
Then several processes that take place on the driver stub are described. 

The module interaction-map displays all binary modules and their interactions 
with the driver stub 36. As can be seen from FIG. 34, the driver stub is used by the 
component 35. More or less, the driver stub acts as a helper to the component 35 by 
filling in all extended Driver functionality possible. 

By taking the module interaction-map in FIG. 34 and displaying all interactions 
taking place with all C++ objects implementing the driver stub, we produce what is called 
the object interaction-map. FIG. 35 is the object interaction-map for the driver stub 36 
component. 

Each object in the diagram is described as follows. 

The CDriverStubDisp object is the dispatch object used to dispatch 
exposed interface methods. During the dispatch process, all raw data is converted 
into the appropriate C++ form. For example, collections of data passed between 
OLE components is usually packaged in a raw block of memory. The 
CDriverStubDisp object takes care of packing outgoing data and unpacking 
incoming data. Data packing involves converting the data between a raw and 
native C++ format. 

The CSPIMgr object is responsible for managing all SPI issues such as 
managing the CSimpleDriver by directing it to connect to the appropriate SPI core 
interfaces exposed by the driver. 

The CSimpleDriver object is used to directly communicate with the driver 
implementing the SPI core interfaces. The CSimpleDriver only communicates 
with the core SPI interfaces implemented by the driver. 
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The following discussion describes all main scenarios, or operations, that occur on 
the driver stub 36. Each scenario-map displays all objects involved, and the interactions 
that take place between them in the sequence that they occur. All operations on the driver 
stub originate from the motion control component 35. In addition to the motion control 
component 35, the XMC Setup Component interacts with the driver stub when installing 
the system 22. It should be noted that all scenarios below assume that the driver stub 36 
has already been registered in the OLE system. Registering this component is the 
responsibility of the setup application and setup component. 

This discussion describes all operations made on the driver stub by the motion 
control component 35. Each section is discussed in the order that they may occur when 
using the driver. 

As shown in FIG. 36, before using the driver stub 36, the motion control 
component 35 must initialize it by creating an instance of the driver stub, and then 
initializing the instance created. Calling the standard OLE function CoCreatelnstance 
completes the first step. After an instance is created, the component 35 must call the 
driver stub exposed Initialize interface method. During initialization, the following steps 
occur. 

The component creates an instance of the driver stub by calling the standard OLE 
function CoCreatelnstance. Once loaded, the CLSID of the driver to use is passed to the 
driver stub when calling its Initialize exposed interface method. When first loaded, the 
driver loads any registration data previously stored. Next, the component 35 passes the 
CLSID, of the driver to use, to the CDriverStubDisp object and directs it to initialize the 
system. The CDriverStubDisp object then directs the CSPIMgr to initialize itself and 
passes the driver CLSID to it. The CSPIMgr passes the CLSID to the CSimpleDriver and 
directs it to only query the core SPI interfaces exposed by the driver. The CSimpleDriver 
loads an instance of the driver then queries all core interfaces exposed by the driver. 

Once the driver stub is initialized, it is ready to perform operations such as 
performing extended Driver functions. FIG. 37 describes the steps that occur when the 
component 35 directs the driver stub to perform an extended SPI operation. The 
following steps occur when the operation is requested. 




First the component 35 must request the operation and pass all pertinent 
parameters to the driver stub. Next, the driver stub directs the CDriverStubDisp to handle 
the operation. The CDriverStubDisp then directs the CSPIMgr to perform the SPI 
extended function and passes the appropriate XMC_EXT_SPI identifier as a parameter. 
The CSPIMgr calls the appropriate function corresponding to the XMC_EXT_SPI 
identifier. The function simulates the extended Driver function and calls the 
CSimpleDriver for core operations. When directed, the CSimpleDriver performs SPI core 
functions by directly calling the exposed interfaces implemented by the driver. 

When the motion control component 35 is finished using the driver stub 36, it 
must release it by calling the exposed Release method. Calling the Release method causes 
the driver stub to free all the resources it uses. FIG. 38 displays this sequence of events. 
During the clean-up process, the following steps occur. 

First the component 35 must direct the driver stub to release all of its resources by 
calling its Release method. When invoked, the driver component passes the call on to the 
CDriverStubDisp object. The CDriverStubDisp object then directs the CSPIMgr to 
release any resources that it was using. The CSPIMgr releases all resources including the 
CSimpleDriver object used. When freed, the CSimpleDriver releases any interfaces used 
from the driver. 

FIG. 39 is an interface map of the driver stub module 36. Attached hereto as 
Appendix F is a document that describes the actual OLE Interfaces exposed, the 
definitions of the data structures used when passing data around, and the definitions of 
each class used internally by the driver. 



The driver administrator 32 is used from two different perspectives. When the 
driver administrator Control Panel Applet 38 is used to configure the system, the applet 
directs the driver administrator 32 to carry out the operations. The applet 38 simply 
provides the user- interface, and the component 35 does the real work of managing drivers 
and streams used with the system 22. Using the driver administrator component with the 
control panel applet is the first perspective on using the component 35. 
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In the second perspective, the motion control component 35 uses the driver 
administrator component to query for the current set of enabled the driver 30. It should be 
noted that, currently, only single driver operation is allowed. Clearly, the system 22 may 
support multiple drivers that are virtualized. For example, if two, four axis, drivers are 
installed, applications using the system could act as though they were using an eight axis 
system. 

This section describes the driver administrator 32 in three main parts. First, all 
modules interacting with the driver administrator component are described along with 
their interactions. Next, the module interaction-map is expanded to display all 
interactions taking place between the C++ objects used to implement the driver 
administrator 32 Component. This description is called the object interaction-map. Then, 
the object interaction-map is tested by running it through several scenarios, or scenario- 
maps. Each scenario-map displays the events and the order in which they occur in a 
certain process taking place on the driver administrator component. 

The module interaction-map shown in FIG. 40 displays all binary modules and 
their interactions with the driver administrator 32 Component. Both the driver 
administrator CPL 38 and the motion control component 35 are the main modules that 
interact with the driver administrator 32 Component. 

The driver administrator CPL module 38 provides the user-interface that allows 
the user to add, configure, and remove drivers and streams in the system 22, The driver 
administrator 32 handles all driver and stream management. Even though the control 
panel applet provides the user-interface, this module 32 does the actual management 
work. 

In addition, the driver administrator is used by the component 35 to access the 
current driver(s) to use when carrying out motion control operations. For example, if the 
AT6400 driver is selected as the current driver when the component 35 queries the driver 
administrator, the driver administrator returns the CLSID of the AT6400 driver. 

Taking the driver administrator 32, displayed in the module interaction-map, and 
displaying all interactions occurring between the C++ objects used to implement the 
administrator 34, produces the object interaction-map therefor. The object interaction- 
map for the driver administrator 32 is shown in FIG. 41. 
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Each object in the diagram is described as follows. 

The CDriverAdminDisp object is the dispatch object used to dispatch exposed 
interface methods. During the dispatch process, all raw data is converted into the 
appropriate C-H- form. For example, collections of data passed between OLE components 
is usually packaged in a raw block of memory. The CDriverAdminDisp object takes care 
of packing outgoing data and unpacking incoming data. Data packing involves converting 
the data between a raw and native C++ format. 

The CDriverlnfoMap object is used to build the information used by the driver 
administrator CPL 38 when displaying information about each driver or stream. 

The CModuleMgr object is responsible for managing all stream and driver 
modules in the system. A list of all drivers registered are stored persistently in the 
registration database by the CModuleMgr. Each time a driver or stream is accessed the 
CModuleMgr is used to get the module. 

The CSimpleDriver object is used to directly communicate with the driver 
component. All OLE specific details are encapsulated within this object. 

The CSimpleStream object is used to directly communicate with the stream 
component. All OLE specific details are encapsulated within this object. 

FIGS. 42-49 describe all main scenarios, or operations, that occur on the driver 
administrator 32. Each scenario-map displays all objects involved, and the interactions 
that take place between them in the sequence that they occur. 

Referring now to FIG. 42, before using the driver administrator component, it 
must be initialized. FIG. 42 describes the process of initializing the driver administrator 
component from either the driver administrator control panel applet or the motion control 
component. During initialization, the following steps occur. 

First, either the control panel applet or the motion control component must create 
an instance of the driver administrator component by calling the standard OLE function 
CoCreatelnstance. Next, the exposed Initialize interface method must be called. When 
the Initialize method is called, the driver administrator component directs the 
CDriverAdminDisp to initialize the system. Next, the CDriverAdminDisp directs the 
CModuleMgr to initialize itself and any modules that it is managing. The CModuleMgr, 
first, loads all information from the registration database. Then for each driver registered, 
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the CModuleMgr creates an instance of the driver by calling the standard OLE function 
CoCreatelnstance. Next, the CModuleMgr calls each drivers Initialize method, passing to 
the method the CLSID of the driver component to attach. The CSimpleDriver attaches to 
the driver component by calling the standard OLE function CoCreatelnstance. 

The driver administrator 32 can register both drivers and streams. Registering 
drivers is very direct, since the driver administrator manages the drivers registered in the 
system. Registering streams, on the other hand, is more complex, since each stream must 
be registered with a driver and the driver manages the streams registered with it, not the 
driver administrator. The following discussion describes the process of registering both 
drivers and streams. 

Registering a driver entails verifying that the module is actually a driver, verifying 
that the driver can be loaded, and storing the driver information in a persistent location. 
FIG. 43 describes this process. When registering a driver, the following steps occur. 

First, the driver administrator CPL passes the name of the driver and directs the 
driver administrator component to register it. Next, the driver administrator component 
passes the driver name to the CDriverAdminDisp and directs it to register the module. 
The CDriverAdminDisp directs the CModuleMgr to register the new driver. The 
CModuleMgr creates a new CSimpleDriver and requests it to register the driver. First the 
CSimpleDriver verifies that the driver is valid by calling its DLLGetModuleType 
exported ftinction. If the function returns XMC_DRIVER_MT the CSimpleDriver then 
calls the driver's exported function DLLRegisterServer to register the module in the OLE 
system. Next the CLSID is queried from the module by calling its exported 
DLLGetCLSID function. The CLSID returned is then used to load the driver by calling 
the standard OLE function CoCreatelnstance. If the CSimpleDriver is successful, the 
CModuleMgr stores the driver CLSID in the registration database. 

Registering a stream is similar to registering a driver, but a little more complex, 
since each stream must be registered with a specific driver. FIG. 44 displays the process 
of registering a stream. When registering a stream, the following steps occur. 

First, the driver administrator CPL passes the CLSID of the driver and the 
filename of the stream to register with the driver, to the driver administrator component. 
The driver administrator component directs the CDriverAdminDisp to register the stream. 





The CDriverAdminDisp object directs the CModuleMgr to register the stream and passes 
the CLSID of the driver and the name of the stream along to it. First, the CModuleMgr 
verifies that the CLSID of the driver one of the registered drivers. If it is not, the driver is 
registered as discussed above. 
5 Next, the CModuleMgr creates a new CSimpleStream object and directs it to 

verify and load the stream component. The CSimpleStream first verifies that the module 
is actually an stream component 28 by calling its exported DLLGetModuleType function. 
If the function returns XMC_STREAM_MT, the CSimpleStream continues and registers 
the stream component by calling its DLLRegisterServer exported function. Finally, the 
10 CSimpleStream object queries the new module for its CLSID by calling the module's 
exported DLLGetCLSID function. The new CLSID is used, by the CSimpleStream, to 
load the stream component using the standard OLE function CoCreatelnstance. If the 
n CSimpleStream succeeds, the CLSID of the stream is passed along to the CSimpleDriver 

:^ who is directed to register the stream. The CSimpleDriver passes the CLSID to the driver 

W 15 component and directs it to register the stream. 

m The following discussion describes setting information in either a driver or stream. 

'f^. When the user edits information in the driver administrator control panel applet 38, the 

5! applet 38 directs the driver administrator 32 to edit the settings for the stream or driver 

m being edited. The following discussion describes how this configuration process works. 

]~ 20 Editing the settings of a driver takes place when the user changes the driver 

□ settings displayed in the driver administrator CPL. Changing these settings causes the 

process described in FIG. 45 to occur within the driver administrator component. The 
following steps occur when setting the driver configuration. 

When driver settings are changed in the CPL 38, the driver administrator CPL 
25 directs the driver administrator component to make the appropriate changes to the driver 
corresponding to the driver handle. A XMC_DRIVER_INFO structure is passed to the 
component 35, describing the new values for the driver. The driver administrator 
component takes the XMC_DRIVER_INFO structure and the handle to the driver and 
passes the information to the CDriverAdminDisp object, directing it to change the settings 
30 in the driver. The CDriverAdminDisp object directs the CModuleMgr to edit the driver 
corresponding to the driver handle. The CModuleMgr locates the CSimpleDriver with the 




handle and directs it to change its settings to those stored in the XMC_DRIVER_INFO 
structure. The CSimpleDriver passes the XMC_DRIVER_rNFO structure to the driver 
component and directs it to change its settings. 

As shown in FIG. 46, when the user edits stream settings in the driver 
administrator CPL 38, the following steps occur. 

After the user changes settings for the stream in the CPL, the driver administrator 
CPL directs the driver administrator component to change the stream's settings and passes 
a handle to the driver containing the stream, a handle to the stream, and a 
XMC_STREAM_INFO structure describing the new values. The driver administrator 
component directs the CDriverAdminDisp object to change the streams settings. The 
CDriverAdminDisp object directs the CModuleMgr to change the settings of the stream 
corresponding to the handle. 

First, the CModuleMgr locates the driver corresponding to the driver handle. 
Next, it requests the CSimpleDriver to change the settings for the stream corresponding to 
the stream handle. The CSimpleDriver searches for the stream corresponding to the 
stream handle and directs it to change its settings to those stored in the 
XMC_STREAM JNFO structure. The CSimpleStream directly communicates with the 
stream component and directs it to change its settings to those in the 
XMC_STREAM_INFO structure. 

There are two different types of information that may be queried from the driver 
administrator 32: the enumeration of all drivers registered, and the driver information 
map. The motion control component 35 uses the driver enumeration when selecting the 
set of drivers to use and control during motion control operations. The driver information 
map, on the other hand, is used by the driver administrator CPL 38 to update the user- 
interface display describing all drivers and streams registered in the system. The 
following discussion describes the process of querying for both the driver enumeration 
and the driver information map. Querying for the driver enumeration occurs during 
the initialization of the motion control component 35. When initializing, the component 
35 must know what drivers to use when performing motion control operations. The driver 
administrator 32 Component is used for that very purpose. Querying the driver 
enumeration just returns a pointer to the IXMC_EnumDriver interface exposed by the 
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driver administrator 32 Component. FIG. 47 displays the events that occur when using 
the interface to get each driver in the enumeration. Using the interface causes, the 
following steps occur. 

First, the motion control component 35 queries the driver administrator 32 
Component for the next driver. Next, the driver administrator 32 Component directs the 
CDriverAdminDisp to get the next driver supported. The CDriverAdminDisp directs the 
CModuleMgr to get the next driver. The CModuleMgr then directs the CSimpleDriver to 
either return the CLSID or a pointer to the lUnknown interface for the driver, depending 
on the parameters of the enumeration. If the CSimpleDriver is requested to return a 
pointer to the lUnknown interface, the interface is queried from the driver component. 

Another set of information that may be queried from the driver administrator 32 
consists of the driver information map. This data is used by the driver administrator CPL 
38 when displaying information describing the drivers and streams registered in the 
system. As shown in FIG. 48, when querying the system for the driver interface map, the 
following steps occur. 

First, the driver administrator CPL 38 queries the driver administrator 32 
Component for the current driver information map. When queried, the driver 
administrator component directs the CDriverAdminDisp to create and load a 
CDriverlnfoMap class. The CDriverAdminDisp creates the CDriverlnfoMap. Next, the 
CDriverAdminDisp passes the CDriverlnfoMap to the CModuleMgr and directs it to load 
the information map. The CModuleMgr queries each driver registered for its internal 
information. Each CSimpleDriver communicates directly with the driver component and 
queries it for all pertinent driver information. Next, the CModuleMgr queries each driver 
for a list of all streams registered with the driver. Using the stream enumeration, each 
CSimpleDriver creates an array of CSimpleStream objects and returns the array to the 
CModuleMgr. For each CSimpleStream object in each array, the CModuleMgr queries 
for all pertinent stream information. Each CSimpleStream communicates directly with the 
stream component and queries it for all information describing the stream. 

After the driver administrator CPL 38 or the motion control component 35 are 
finished using the driver administrator 32, they must release the component 35 to free any 
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resources it was using. FIG. 49 describes this process. When cleaning up after a call to 
the Release method, the following steps occur. 

First, either the driver administrator CPL 38 or the motion control component 35 
must direct the driver administrator 32 Component to release itself by calling its Release 
method. Next, the driver administrator component directs the CDriverAdminDisp object 
to free all resources used in the system. The CDriverAdminDisp then directs the 
CModuleMgr to free any resources that it is using. First, the CModuleMgr traces through 
all CSimpleDriver objects, querying each for their CLSID and enabled state. Next, each 
CSimpleDriver is freed. Each CSimpleDriver object freed, frees all arrays of 
CSimpleStream objects registered with it. When freed, each CSimpleStream object 
releases all interfaces that it was using from the stream component. In its fmal clean-up, 
each CSimpleDriver releases all interfaces that it was using from the driver component. 
All CLSID and enabled state information is stored persistently in the registration 
database. 

FIG, 50 depicts an interface map for the driver administrator 32. Also, attached 
hereto as Appendix G is a document that describes the actual OLE Interfaces exposed, the 
definitions of the data structures used when passing data around, and the definitions of 
each class used internally by the driver administrator 32 component. 



This document describes the design of the driver administrator control panel applet 
38 (CPL) that is used by the user to add, configure, and remove both drivers 30 and 
stream components 28 later used by the component 35 when directed to carry out motion 
control operations. With regard to design, there are three main types of "views" used to 
look at how the control panel applet works. 

First, a module interaction map shown in FIG. displays all main executable and 
user-interactable items, or modules, that the CPL uses and interacts with. For example, 
when a dialog is displayed by the CPL executable, both the dialog and the CPL modules 
are considered to interact with one another. Technically, the dialog is not a module since 
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it is a figment displayed on the screen, but none the less, module interaction maps classify 
them as such since they are key destination points for user-input. 

Second, an object interaction map shown in FIG. 52 displays all main objects 
making up the modules described in the module interaction map. Objects consist of the 
actual instances of C-H- classes defining each object. All interactions between the objects 
are drawn out in this interaction map. 

Finally, FIGS. 53-57 display a set of scenario maps are drawn out using the object 
interaction map as a basis. Scenario interaction-maps describe the interactions taking 
place during a specific operation. Initialization, Adding a driver to the system, and 
Viewing the support offered by a driver, are all examples of a scenario interaction-map. 

The design goals for the driver administrator 32 are the following: 

1 . User-Interface separation - Implement all user-interface elements used to 
control the driver administrator 32 Component. 

2. Upgradable to OCX Client - Eventually each driver and stream may 
implement all UI elements with an OCX that then passes all input to the 
corresponding driver or stream. The driver administrator CPL 38 must be 
designed in a way that is easy to upgrade to become an OCX client. 

3. Provide Stream Independence - drivers 30 should not be required to use 
streams 28 in order to operate. The design of the driver administrator 32 must 
make amends to ensure that it is not dependent on stream component 28 operations 
to operate. 

4. Use Windows 95 UI - When ever possible, Windows 95 UI elements 
should be used. For example, TreeViews, ImageLists, Button Bars, Tab Dialogs 
and any other UI elements should be put to use to ensure a Windows 95 look-and- " 
feel 

The following discussion describes the module interaction map for the control 
panel applet 38. A module is defined as either an executable binary, an external data file, 
or a main user-interface element used when interacting with the user. FIG. 51 is a 
drawing of all modules that interact with each other when running the driver administrator 
control panel applet. 




The driver administrator CPL 38 is a control panel applet. And, a control panel 
applet is a special DLL that exports several functions allowing the Windows Control 
Panel to communicate with the applet. 

The Driver Administrator Dialog is the main dialog that appears when selecting 
the control panel applet icon from the Windows Control Panel. 

The Browse Dialog is used to query the user for a filename. For example when 
adding a new stream or driver, the driver administrator uses this dialog to ask the user for 
the location of the new driver or stream to add. 

The View Support Dialog displays the support provided by the selected driver 30. 
Each driver may support a different set of extended functionality. This dialog shows the 
user exactly how much support is provided by each driver allowing them to determine 
which functions within their application may not operate when using the driver. 

Unlike the Module Interaction-Map described above, the Object Interaction-Map 
shown in FIG. 52 describes how the actual instances of C-H- objects interact with one 
another within each module. 

Other than showing that each dialog is managed by the object, whose name is 
displayed in the dialog, the main difference from the module lA-map are both the 
CComCPL and CDriver Admin C-H- objects. Both objects are described below. 

As the description of each dialog class is fairly straight forward and very similar to 
the dialog description above they will not be described in this section. This section will 
describe all other C-H- objects. 

The CComCPL is a C-J-+ object that is generated by the COMBuilder application 
from a template. It is used to handle all Windows messages sent from the Control Panel 
Application. 

The CDriverAdmin object is used to drive, control, and manage the use of the 
driver administrator 32 Component. For example, all OLE 2.0 interface management and 
data translation is handled by this object. Data translation involves translating data from a 
standard C-^+ format to a raw format that is handled easily with the OLE 2.0 data transfer 
mechanisms. 

Scenario Interaction-Maps are almost identical to object interaction-maps but they 
only display the objects and interactions taking part in a specific operation. Also, each 




interaction is numbered by the sequence in which they occur while the operation is 
running. The following discussion describes several key operations that occur while 
running the driver administrator CPL 38 Applet. 

Initialization occurs when the user first runs the CPL Applet. During this process 
all other objects are initialized and several modules are loaded. There are two steps that 
take place during the initialization process: First the application is initialized, and second 
the dialog is initialized with values queried from the driver administrator 32 Component. 
The following sections describe each. 

Initializing the application, which is shown in FIG. 53, occurs when the 
application is first run and the main dialog has not yet been displayed. When initializing 
the application, the following steps occur. 

Through a Windows message, Windows notifies the CComCPL object that the 
Control Panel Applet has just been loaded. CComCPL then loads the 
CDriverAdminDialog and tells it to do any dialog prepping before going modal. Next, 
CDriverAdminDialog loads any settings stored in the Registration Database. For 
example, the current window position and active tab may be stored in the database. 
CDriverAdminDialog then Loads the CDriver Admin class and directs it to initialize itself. 
During initialization, CDriverAdminDialog creates an instance of the driver administrator 
32 and queries all interfaces that will be used. 

Once the application is initialized, the defauh settings to be displayed in the dialog 
must be set. These values are set when the dialog is initialized, just before displaying it. 
FIG. 54 describes this process. During the process of initializing the dialog, the following 
steps occur. 

During the dialog preparation that occurs before the DoModal call, 
CDriverAdminDialog queries the CDriverAdmin object for the driver enumeration to be 
used when setting initial values to be displayed in the dialog box. CDriverAdmin uses the 
driver administrator 32 Component to query for the driver information map, which is then 
passed back to the CDriverAdminDialog. Once receiving the driver information map, the 
CDriverAdminDialog uses the information to update all user-interface items related to 
either drivers or streams. 
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Adding a driver to the system 22 can be broken down into two steps. First, the 
module name must be added to the system. Next, the driver administrator 32 main dialog 
must update itself to reflect the new driver just added. 

Adding a driver occurs when the user presses the "Add..." button on the driver 
administrator 32's main dialog. FIG. 55 describes this process. When adding a new 
driver, the following steps occur. 

When adding a driver, first the user must press the "Add..." button. After pressing 
the button, CDriverAdminDialog opens up the common open file dialog. The user must 
enter in the filename of the driver to add and close the dialog. CDriverAdminDialog then 
passes the filename to the CDriver Admin object and calls the RegisterDriver method 
passing in the name of the module to register as a driver. CDriverAdmin then passes the 
driver filename to the driver administrator 32 Component and directs it to register the 
driver in the system 22. 

The process of updating the main dialog is identical to the process of initializing 
the dialog discussed above. 

Similar to the process of adding a new driver, removing a driver involves both 
removing the driver from the system and then updating the main dialog. Pressing the 
"Remove" button removes a driver from the XMC software system. FIG. 56 describes 
this process. The following steps occur when removing a driver. 

To remove a driver, the user must first select the "Remove" button. After pressing 
the button, the selected driver or parent driver to the selected stream will be removed, 
CDriverAdminDialog passes the XMC_HDRIVER of the driver to the CDriverAdmin and 
directs it to remove the driver by calling its UnRegister method. CDriverAdmin passes 
the XMC_HDRIVER to the driver administrator 32 Component and directs it to 
UnRegister the driver. 

The process of updating the main dialog is identical to the process of initializing 
the dialog discussed above. 

Viewing Support involves viewing the level of support implemented by the 
selected driver. FIG. 57 describes the process of providing this information to the user via 
the View Support Dialog. The following steps occur when viewing the support provided 
by the driver. 
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First the user must select the "View Support" button on the driver administrator 
main dialog. When selected, CDriverAdminDialog queries CDriverAdmin for the driver 
support information. CDriverAdmin passes the query on to the driver administrator 32 
component who actually fills out the information. Once the queried information is 
returned, the CDriverAdminDialog passes it on to CViewSupportDialog. 
CViewSupportDialog initializes itself using the driver support information. 

Attached hereto as Appendix H is a document that describes the actual OLE 
Interfaces exposed, the definitions of the data structures used when passing data around, 
and the definitions of each class used internally by the driver administrator 32. 



VIII. DRIVER ADMINISTRATOR CPL APPLET 

This section contains a description of the driver administrator control panel applet 
38. When using the driver administrator 32 to configure the motion control system, there 
are two main items that the user will work with: drivers and streams. Each driver 30 
generates the hardware specific, control codes that are then sent to the selected stream 
component 28, Streams facilitate the data transport layer between the driver and the 
control-code destination. 

Depending on the current hardware setup, different streams may be used. For 
example, if the hardware is connected to the PC Bus, a PC Bus stream will be used to 
communicate to it. On the other hand, if the hardware is connected through a serial cable 
to a serial I/O Port, the serial stream will be used. Finally, all hardware configurations 
may use the file stream. When using the file stream, all control-codes are sent to the 
specified file that can be downloaded to the hardware at a later time. 

This section describes both drivers and streams, and how each is configured. This 
section initially describes the driver items and all property pages used to edit them. This 
section also contains a description of the streams and their property pages. Finally, this 
section describes the about box containing details on the Software, 

The main purpose of each driver is to generate the hardware-specific control-codes 
directing the hardware to carry out specific motion control actions. For example, such 
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actions may include querying the hardware for the current position or directing the 
hardware to move to a predetermined location in the system. The following discussion 
describes the property pages used to configure each driver. 

There are two types of properties affecting each driver. First, a set of defaults may 
be set that are used by the motion control component 35 as recommended values. The 
scaling and units used are several example default values. In addition to setting default 
values, if the driver supports more advanced configuration, pressing the Advanced... 
button will display a dialog box used to set the driver configuration. For example, if a 
driver does not support streams, the advanced configuration dialog, provided by the 
driver, will allow the user to set the I/O Port and IRQ settings. 

The properties affecting drivers 30 are as follows. 

Scaling - Setting the scaling property affects the default scaling used on all 

axes within the motion control system. The range for scaling values is (0.0, 1.0]. 

Default setting may be overridden when programming XMC by using the 

IXMC_StaticState interface. 

Units - Setting the units property affects all coordinates used when 

programming the system 22. 

The unit descriptions are as follows: 

MM ENGLISH - Inches are used as the base unit for all coordinates 

MM_METRIC - Millimeters are used as the base unit for all coordinates. 

MM_NATIVE - The native coordinates defined by the hardware system are used. 

Coordinates used to program XMC are mapped 1 : 1 to the hardware coordinates. 

Advanced... - Pressing this button will display a dialog used to edit any advanced 

properties for the driver that may be edited by the user. 
In addition to allowing the user to set properties, each driver property page displays the 
fijU names of both the hardware supported and the hardware vendor who makes the 
hardware. 

The buttons along the bottom of the windows work with the selected driver or 
stream. The following discussion describes each button and what it does. 
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Pressing the Make Default button selects the current driver to be the default. If a 
stream is selected, its parent driver becomes the default driver. The default driver is later 
used by the motion control component 35 

Selecting the Add... button, displays the Add Module dialog. This dialog is used 
to add new drivers and streams to the system 22. Once selected, the new driver or stream 
will be displayed in the Driver tree view. When adding a stream, the stream is added 
under the currently selected driver. To enable the stream, you must select the enable 
check box located in the streams property page. 

Selecting the Remove button, removes the current driver or stream selected. If a 
driver is removed all of its streams are also removed. 

Selecting the View Support... button displays a dialog used to view the level of 
XMC support implemented by the driver. For example, all API interfaces and subsequent 
methods are displayed. If a lack of implementation within the driver prohibits an API 
interface from operating, the driver stub 36 is used. If the lack of implementation within 
the driver 30 cannot be replaced by operations within the driver stub 36, the interface or 
method is disabled. 

The following are descriptions of each graphic found in the XMC Support View 

Dialog. 

D - This graphic means that the interface or method is implemented by the driver 
30. 

S - This graphic means that the interface or method is implemented within the 
driver stub 36. 

X - This graphic means that the interface or method is disabled because of a lack 
of implementation within the driver 30. 

Like the properties page, a debug page is also provided to set all debugging 
settings for the driver. Each driver may specify that all API calls used to control the 
driver are logged. The logging settings only affect the current driver selected. The 
Output field allows you to select the output stream where all debug information is sent. 
When Streams is enabled, debug information is sent to the specified text file. When 
Debug Monitor is enabled, debug information is sent to the debug monitor if it is running. 
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Using Enable to enable a stream turns it on causing all debug information generated to be 
sent to the stream. More than one stream may be enabled at one time. 

Stream Settings are available for each debug stream supported. Text File allows 
the name of the text file may be set. The Debug Monitor can only be enabled and 
disabled. 

A stream is the transport layer used by the driver to pass data to the destination 
location. The destination location may be the actual motion control hardware or even a 
text file. Usually the control language used by a hardware vendor is supported by several 
different flavors of their motion control hardware. For example, some vendors have both 
PC Bus based and Serial I/O based motion control hardware that understand the same 
control language. In such a case, the same driver would be used for each hardware setup 
but it would communicate with different streams depending on the specific hardware 
setup. Graphically, each stream is listed below each driver that uses the stream. 

This section describes the streams supported by the system 22 and how they are 
configured. 

The PC Bus stream sends all data directly to a PC Bus based motion control 
hardware system by writing to the specified I/O Ports and IRQ's defined by the hardware. 
This section describes both the properties and debug settings available for the PC Bus 
Stream. 

Stream properties only affect the currently selected stream. The user is required to 
select certain settings, such as the I/O Port and IRQ. Without setting these values, the PC 
Bus Stream will not be able to communicate with the hardware. The properties affecting 
PC Bus Streams are described below. 

The I/O Port is the base port used to communicate with the motion control 
hardware that the stream is to send data to. 

The IRQ is the interrupt request level used by the hardware. 

Pressing the Advanced... button will display a dialog allowing the user to edit 
more advanced stream options. For example, if the stream supports a Port I/O map that 
the user can edit, the port map would be displayed in this dialog. This button is only 
enabled for streams supporting advanced features that the user may edit. 
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When debugging an application program it may be useful to see what codes are 
actually sent to the hardware. The Debug Settings page for streams allows the user to 
enable and disable both the Cmd and Bit Streams. The Cmd Stream is used to log all 
command-codes sent to the hardware. If this level of detail does not provide you with 
enough information, the Bit Stream may be used. When enabled, the Bit Stream logs all 
values sent through each hardware port. All values read from and written to each port 
used by the hardware are logged. Note, when enabled, both streams may significantly 
slow down the application programming the motion control system. 

Serial RS-232 Streams are used to send data from the driver to motion control 
hardware connected to the computer through the serial I/O port. Both property and debug 
settings only affect the selected Serial RS-232 Stream. The following discussion 
describes the available settings in each in detail. 

All Serial RS-232 property settings must be set by the user for they let the stream 
know what I/O port and communication protocol to use when communicating with the 
hardware. The properties affecting Serial RS-232 Streams are as described below. 

The Port is the serial port that the hardware is connected to. COMl - COM4 are 
valid ports that can be used. 

The Baud Rate is the speed of data transmission supported by the hardware. 

When Hardware is selected a more efficient, but less compatible, communication 
protocol is used to communicate to the hardware. If errors occur when this protocol is 
selected, use the XON/XOFF communication protocol. 

When the XON/XOFF communication protocol is selected a simple and more 
compatible communication protocol is used. 

Debug settings for the Serial RS-232 Stream are very similar to those supported by 
the PC Bus Stream. Serial RS-232 Streams only support command logging through the 
Cmd Stream and do not support bit logging. 

The Text File Stream is used to build control-code programs for later use. Using 
this stream facilitates running the XMC software in code-generation-mode. No motion 
control actions take place when running in this mode. Instead, control-code programs 
may be built and stored to file. Later, after programs are built and saved, they may be 




-49- 



downloaded to the motion control hardware and run. The following discussion describes 
the property and debug settings for the Text File Stream. 

The main property set, when configuring a Text File Stream, is the actual name 
and location of the file to use. Once set, the stream is ready for use. 

The following properties may be configured for the Text File Stream: 

Filename is the filename and location of the file used to store all control-codes 
generated by the driver 30 selected. Pressing the Browse.., button displays a dialog 
allowing you to graphically select the location and filename to use. 

No debug settings are available for the Text File Stream. 



FIG. 58 contains a module interaction map depicting a language driver 44 and 
illustrating how that language driver 44 interacts with the streams 28, the driver 
administrator 32, the motion control component 35, and the registry 42. 

As with the software drivers 30 described above, one language driver 44 is used 
for each of the motion control devices 20 of the group of supported motion control 
devices. The language drivers 44 perform the same basic function as the software drivers 
30 described above with reference to FIGS. 1 and 12-21. To the software system 22, the 
language drivers 44 are accessed and respond in the same manner as the software drivers 
30; the differences between the language drivers 44 and the software drivers 30 are 
entirely internal. 

The primary difference between these drivers 30 and 44 is that the language 
drivers 44 use a database the key fields of which are an index field, a command format 
field, and a response format field. Each record or row in the database corresponds to a 
given Driver function. 

The purpose of the command and response format templates is to formalize and 
simplify the process of constructing command data strings and format data strings which 
contain commands and parameters to be transmitted to the motion control devices 20. 
The format templates define how, for a given SPI command, the software system 22 
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communicates with a vendor specific hardware command language associated with a 
given motion control device 20 associated with a given language driver 44. Accordingly, 
one database containing command format templates and response format templates will be 
created for each such language. 

The command format field contains a command format template, and the response 
format field contains a response format template. Each of these templates comprises a 
sequence of data type identifiers, macro identifiers, syntax characters, and/or ASCII 
characters. 

The index field contains a value unique to each Driver function that facilitates the 
process of looking up the command and response format templates associated with a 
given Driver function. 

The software system designer defines the data type identifiers, macro identifiers, 
and syntax characters discussed above. In general, the data type identifiers and syntax 
characters are common to both the command format template and the response format 
template. 

The macro identifiers will normally correspond to macros that are associated with 
either the command format templates or the response format templates. The ASCII 
characters are defined by the Driver fianction and the particular motion control device 20 
with which a given language driver 44 is associated. 

An Excel spreadsheet may be used as an organizational tool that facilitates 
creation of the database used by the language driver 44. An example of a Excel 
spreadsheet that may be used for this purpose is shown in FIG. 67. The spreadsheet 
shown in FIG. 67 is saved as a tab-delimited file and then copied into the SPI database 
shown in FIG. 59. 

The spreadsheet shown in FIG. 67 is simply an organizational tool and will not be 
described herein in detail. But it should be noted that the exemplary spreadsheet shown in 
FIG. 67 sets forth a list of typical command and response data type identifiers, along with 
descriptions thereof, and lists of command and response macros. These will be 
supplemented by an additional STRUCT data type that allows the programmer to define a 
data type that combines the other primitive data types as necessary for a given template. 
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The language drivers thus operate generally as follows. As described above, the 
motion component 35 will call the driver function implemented by the language driver 44 
and, in many cases, will pass parameters necessary to carry out that function. The 
language driver 44 will use the index for that driver function to look up the command 
format template and the response format template associated with the appropriate driver 
function. 

Using the command format template, the language driver 44 will construct a 
command data string containing ASCII characters. The command data string carries the 
commands and parameters necessary to implement the given driver function in a desired 
manner on the motion control device 20 associated with the language driver 44. 

Similarly, the language driver 44 uses the response format template to parse a 
response data string sent by the particular motion control device 20 in response to the 
command data string. The response format template thus allows the language driver 44 to 
pass from the motion control device 20 to the motion control component 35 any 
commands and/or parameters necessary to enable the controlling application 26 to 
function as intended. 

The following sets forth examples of the process of generating a command data 
string and parsing a response data string given a set of command and response format 
templates associated with a single SPI. 

EXAMPLE 1 

The first example illustrates how the language driver 44 might deal with the Driver 
function IXMC_DrvExt_Test::Move. 

Cmd Format: D%d,+:@[snd]GO%b+:@[snd] 

Rsp Format: @[crlf|>@[rcv]@[crlfl>@[rcv] 

Driver function Call: pXMCDrvExtTest->Move( 20.0, 30.0 ) 

This function call directs the motion control device to move 20 units in the x 
direction and 30 units in the y direction. 

The driver communicates with the stream as follows: 

5 ^ 
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Step 1 . Perform the operation in the command format template up to the first @ 
symbol. This builds a raw command string of "D20.0,30.0:" 

Step 2. After the first @ symbol is the send command, which sends the string that 
was built in step 1 . The language driver has now reached the G in the command format 
template. 

Step 3. After the send command, the language driver reads a response from the 
stream to confirm that the command string was received and processed correctly. The 
response string received from the stream is as follows: "\r\n>". 

Step 4. The language driver next uses the response format template to parse the 
raw response string to verify operation and extract data. The language driver then picks 
up at the G in the command format template and constructs the next raw command string 
of "GOl 1", leaving off at the last macro. 

Step 5. The language driver, picking up at last macro in the command format 
template, then sends the raw command string created in step 4 to the stream, completing 
the command format template. 

Step 6. Again, after the send command the language driver receives a response 
data string from the stream as follows: "\r\n>". 

Step 7. The language driver next parses the response data string received in step 6. 



The second example illustrates how the language driver 44 might deal with the * 
Driver function IXMC_DrvExt_Test:: Set Velocity. 



Cmd Format: 



V%lf,+:@[snd] 



Rsp Format: 



@[crlf|>@[rcv] 



Driver function Call: pXMCDrvExtTest->SetVelocity( NOP, 22.0 ) 



Explanation 



Set the velocity of the y axis to 22.0. 



Raw Command String: 



tl 



V,22.0: 



Raw Response String: "\r\n>" (expected) 





EXAMPLE 3 



The third example illustrates how the language driver 44 might deal with the 
Driver function 

IXMC_DrvExt_Test::GetVelocity. 
5 Cmd Format: GV%b+:@[snd] 

Rsp Format: %d,+@[crlf|>@[rcv] 

Driver function Call: pXMCDrvExtTest->GetVelocity( NOP, &dfY_VeI ) 
Explanation Get the velocity set for the y axis. 

Raw Command String: "GVOl :" 
10 Raw Response String: •',44.0\r\n>" (expected) 
•2 dfY Vel = 44.0 

!;! EXAMPLE 4 

irsf 
- '- 

ifi The fourth example illustrates how the language driver 44 might deal with the Driver 

fi function IXMC_DrvExt__Test: :Reset. 

□ 15 Cmd Format: !RESET:@[snd]MAO:MCO:LHO:@[snd] 

p Rsp Format: ©[crlf]* VENDOR NAME - MODEL@[rcv]@[crlfl>@[rcv] 

''z. I 

□ Driver function Call: pXMCDrvExtTest->Reset() 
Explanation Reset the hardware. 

Raw Command Stringl : "IRESET:" 

20 Raw Response String 1 : 'V\n* VENDOR NAME - MODEL" (expected) 

Raw Command String2: "MAO:MCO:LHO:" 

Raw Response String2: "\r\n>" (expected) 

While the language driver 44 is of particular importance in the context of the 
software system 22 described above, this technology may have broader application to any 
25 hardware in which ASCII strings are employed to transmit commands to and receive 
responses from hardware. 
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The language driver 44 will now be described in more detail. The language driver 
44 is used by both the driver administration 32 and the motion control component 35. Its 
main purpose is to implement functionality that generates motion control commands for 
the specific hardware supported. 

For example, the AT6400 driver used to control the Compumotor AT6400 motion 
control hardware, generates AT6400 command codes. During the initialization phase of 
the system 22, the driver administrator 32 communicates with each language driver 44, 
allowing the user to add, remove, or change the configuration of the driver 44. When an 
application using the system 22 is run, the component 35 communicates with the language 
driver 35 directing it to carry out the appropriate motion control operations. 

Unlike the driver 30 described above, which communicates with motion control 
devices 20 by directly sending binary codes, the language driver 44 sends ASCII text to 
the stream 28, which then sends the information on to the motion control device 20. 

This section makes reference to a number of drawings to describe the features 
implemented in the language driver 44: (a) the Module Interaction-Map in FIG, 58 that 
displays all binary modules that interact with the driver and how they interact with one 
another; (b) an Object Interaction-Map (FIG. 59), which corresponds to the module 
interaction map expanded to display the internal C++ objects making up the language 
driver 44, and how these objects interact with one another; (c)a number of Scenario Maps 
(FIGS. 60-65) that display the interactions taking place between the C++ objects involved 
during a certain process; (d) an interface map that describes the interfaces exposed by the 
language driver component 44, all data structures used, and the definitions of each C++ 
class used; and (b) a table illustrating how a typical database employed by the language 
driver 44 is constructed (FIG, 67). 

The module interaction-map in FIG. 58 displays all binary modules and their 
interactions with the Language Driver 44. There are two modules that interact directly 
with the driver 44: the Motion Control Component 35, and the Driver Administrator 32. 
The driver administrator 32 queries and changes the drivers settings and the component 35 
directs the driver 44 to carry out motion control operations, such as moving to a certain 
location in the system. 
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Mores specifically, the module interaction-map shown in FIG. 58 contains the 
following modules: 



The Driver Administrator module 32 is used to install, uninstall, 
register, and setup each driver and stream module. 

The Motion Component is the motion control component 35 used by 
applications 26. The component 35 communicates with the current driver 44 passed to it 
by the driver administrator 32 to carry out motion control operations requested by the 
application 26. 

The Language Driver 44 generates the ASCII codes making up the 
hardware command language. A given language driver 44 only communicates with a 
stream 28 that has been specifically connected to that driver 44. Once connected, the 
stream 28 is used to communicate with the destination object, such as the PC Bus, serial 
I/O connection, text file, or debug monitor. 

The Streams 28 are the actual objects that operate as the data transport 
layer for each driver 44. Each stream 28 has a different target that defines the type of the 
stream. 

The Registry 42 is the standard Windows registration database. 
The object interaction-map in FIG. 59 breaks the module interaction-map shown in 
FIG. 58 down into more detail by including the interactions taking place between all C-H- 
objects used to implement the driver 44, 

Each object in the diagram is described as follows. 

CDriverObjectThis is the main C-H- object that implements all OLE 
specific functionality including the function shells for all OLE interfaces exposed by the 
object. 

CDrvCoreDisp This is the C-H- object used to dispatch all core SPI 
OLE interface functions to their respective internal implementations. In addifion to the 
methods inherited from the CLangDrvCoreDisp object, this object dispatches driver 
specific SPI, such as the core XMCSPI OLE interface methods. 
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CLangDrvCoreDisp All language driver core functionality is dispatched 

through this object to its internal implementation. For example, the generic language 

driver implementation for initialization is dispatched through this object to its 

implementation residing in the LANG_DRV basecode library. 

CDrvExtDisp This is the C++ object used to dispatch all extended SPI 
OLE interface functions to their respective internal implementations. In addition to the 
methods inherited from the CLangDrvExtDisp object, this object dispatches driver 
specific SPI, such as the extended XMCSPI OLE interface methods. 

CLangDrvExtDisp All language driver extended functionality is 
dispatched through this object to its internal implementation. For example, all stream 
handling is dispatched through this object to its implementation residing in the 
LANG_DRV basecode library. 

CCommandMgr This object is used to build commands sent to the 
stream, and extracting responses received from the stream. The CCommandMgr is the 
controlling object that manages the CCommand, CResponse, and CCommandDatabase 
objects. 

CCommand The CCommand object builds command strings that are 
then sent to the CSimpleStream. Each command built is a complete motion control 
command string. 

CResponse This object converts raw response strings, returned by the 
CSimpleStream, and converts them into C++ data types. For example, a response string 
containing position data may be converted into a set of double values. 

CCommandDatabase This object stores the complete database of 
commands making up the motion control command language. The database may be 
represented as an actual external database (such as a SQL database), a text file, or stored 
inside the driver as a custom resource. Currendy, the language driver only supports 
databases stored as a custom resource within the driver module. 

CSPIInfo This object makes up one database entry stored within the 
CCommandDatabase object. 



5i 



^ -57- ^ 

CStreamMgr This object is responsible for managing the set of streams 
registered with the driver. Streams, may be added, removed, and enabled. Only enabled 
streams actually send data to their targets. For example, only an enabled PCBus stream 
will send data to the motion control card plugged into the PCBus. 

CSimpleStream This object is used to initialize, create, and 
communicate directly with the underlying stream component. 

CDriverlnfoMgr This object is responsible for creating the 
CDriverlnfo object. 

CDriverlnfo This object contains the complete set of state data making 
up the Language driver 44. All driver settings and a list of all XMC Streams used are 
stored within this object. Basic queries are routed directly to this object. More complex 
operations are handled by one of the various manager objects, who connect to this object, 
perform the operation, and then disconnect from it. 

CRegistryMgr This object is used to save and load the information, stored 
within the CDriverlnfo object, to and from the registration database. In specific, contains 
the code called when the ICOM PersistRegDB interface is invoked. 

CRegistry This object performs all registration database operations 
such as creating keys, saving values, and querying values. 

All main scenarios, or operations, that occur on the Language Driver 44 will now 
be described with reference to FIGS. 60-66. Each scenario-map contained in these figures 
displays all objects involved and the interactions that take place between them in the 
sequence that they occur. 

There are two types of operations that occur on the Language driver 44. First, the 
Driver administrator 32 may initiate operations, such as adding streams or configuring the 
driver. And second, the Motion control component 35 may initiate operations on the 
driver when an application is actually running. 

Referring now to FIGS. 60-64, all operations made on the driver 44 by the driver 
administrator 32 will be described. Each figure is discussed in the order that it may occur 
when using the driver 44. 
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Before a driver may be used by the XMC Motion Component, it must be 
registered in the OLE system. As shown in FIG. 60, in order to register a driver the driver 
administrator, first verifies that the module being registered is actually an appropriate 
language driver, then it calls the DLLRegisterServer exported function to register the 
5 driver. Each module of the system 22 exports a function called DLLGetModuleType. 
This function is used to verify that the module is an appropriate driver component. 

Next, the driver administrator can load the component using the OLE 
CoCreatelnstance function. During the initialization process, the driver loads all 
registration data and initializes the CDriverlnfo and all C++ manager objects. 

10 The following describes in detail each of the steps set forth in FIG. 60, 

1 . During initialization, the driver administrator must load the DLL, 
containing the stream component, verify that the module is an XMC Driver. To do so, the 
driver administrator calls the DLLGetModuleType function, exported by the driver. If the 
function returns a value that contains the value XMC_DRIVER_MT in the high byte, then 

15 the driver administrator proceeds and registers the driver by calling its exported function, 
DLLRegisterServer. When called, the implementation of the DLLRegisterServer writes 
all OLE 2.0 registration information, needed to register the OLE component, to the 
Windows registration database. 

2. Next, the driver administrator must query the driver module for its CLSID. 
20 Calling the driver's exported function, DLLGetCLSID, returns the CLSID. Once it has 

the CLSID, the driver administrator may create an instance of the driver by calling the 
standard OLE function CoCreatelnstance. 

3. CoCreatelnstance automatically initializes the component by calling the 
ICOM_Base::Initialize method implemented by the CDriverObject. 

25 4. The implementation of ICOM_Base::Initialize directs both the 

CDrvCoreDisp to initialize itself 

5. Within its initialization, the CDrvCoreDisp object initializes each of its 
manager objects, starting with the CcommandMgr. 
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6. During its initialization, the CCommandMgr directs the 
CCommandDatabase to load itself. 

7. To load the database, the CCommandDatabase object reads in the database 
and builds the CSPIInfo list of database elements. 

8. . After initializing the CCommandMgr, the CDrvCoreDisp object directs the 
CDriverlnfoMgr object to create the CDriverlnfo object, that will later store the internal 
state of the Language driver 44 component. 

9. The CDriverlnfoMgr object creates the CDriverlnfo object and passes it 
back to the dispatch object. The pointer to this object is later stored in the components 
state handle, when the CDriverObject calls ICOM_Base2::SetStateHandle. 

10. Next, the CDrvCoreDisp object initializes the CStreamMgr, that is used to 
perform all stream operations. 

1 1 . Next, the CDrvCoreDisp object initializes the CRegistryMgr, that is used 
to perform all registration database operations. 

12. Finally, the CDriverObject initializes the CDrvExtDisp object. 

It should be noted that all initialization is initiated through the COM Auto-Init 
mechanism. Auto-init occurs when creating an object. When calling either 
CoCreatelnstance, or calling the IClassFactory::CreateInstance method, the internal COM 
implementation calls the ICOM_Base::Initialize method. This method triggers the 
complete initialization process described in this section. 

After initializing the driver, the driver administrator may perform operations on it. 
For example, the driver administrator may request the driver to add or remove a stream. 
Figure 61 displays the sequence of events occurring when the driver is requested to add a 
new stream. 

When adding a stream, the following steps occur: 

1 . The driver administrator directs the driver to add a new stream and passes 
the filename and CLSID of the stream, to be added, to the driver. 
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2. The driver then passes the filename and CLSID to the CDriverObject 
object and directs it to add the stream by calling its CLNGStreamMgmt::AddStream 
embedded C++ class method. 

3. The embedded C++ object, that implements the OLE interface, directs the 
CDrvExtDisp object to add the stream, passing it a handle of the component state data. 

4. The CDrvExtDisp object first typecasts the component state data into a 
pointer to the CDriverlnfo object. 

5. Next, the CStreamMgr, is connected to the CDriverlnfo object pointer, and 
directed to add a new stream. 

6. In order to add the new stream, the CStreamMgr, uses a CSimpleStream to 
load and create the stream component. 

7. The CSimpleStream object first sets function pointers to the DllGetCLSID, 
DllGetModuleType and DllRegisterServer functions exported by the component. Before 
loading the module, the CSimpleStream, first makes sure that the module is actually an 
XMC Stream by comparing its module type with the XMC_STREAM_MT module type. 
If it is, the component is registered in the registration database as a n OLE component. 

8. Using the DllGetCLSID queried in the previous step, the CSimpleStream 
gets the components CLSID and calls CoCreatelnstance to load an instance of the OLE 
object. 

9. After the CSimpleStream completes, the CStreamMgr adds the stream to 
the CDriverlnfo's stream array. 

Another operation requested from the driver, after initialization, is that of querying 
it for its current settings. Before displaying information about the driver, like the name of 
the hardware it supports, the driver administrator must query the driver for the 
information. FIG. 62 displays an exemplary process of querying the driver for its driver 
settings. 

When querying the driver for information, the following steps are performed. 

1 . The driver administrator, calls the interface method used to query the 
driver's information and passes the call a pointer to the XMC_DRIVER_INFO structure. 




-61- 



10 




-2 



20 



2. The call is handled by the implementation of the OLE interface method, 
implemented by on of the CDriverObject's embedded C++ classes. 

3. The embedded C++ object, used to handle the interface, directs either the 
CDrvCoreDisp or CDrvExtDisp object to carry out the operation, and passes the object th 
handle to the component state data. 

4. The dispatch object type casts the state handle to a CDriverlnfo object 
pointer. Once converted, the CDriverlnfo object is queried for the appropriate data. 

Upon request, the driver may either save or load its entire configuration to or from 
the registration database. This operation is used by the XMC Driver Administration 
component who stores all XMC configuration data in the registration database, FIG. 63 
displays the sequence of events that take place when the XMC Driver Administration 
component directs the driver to load its information from the registry. 

During the registration process, the following steps occur. 

1. First, using the ICOM_PersistRegDB OLE interface, exposed by the 
driver, the driver administrator directs the component to load its configuration data. 

2. The CDriverObject's embedded object, used to handle all 
ICOM_PersistRegDB calls, is invoked and performs the operation. 

3. Once invoked, the embedded object directs the CDrvCoreDisp object to 
perform the load, and passes it a handle to the components state data. 

4. The CDrvCoreDisp object, first typecasts the state handle to a CDriverlnfo 
object pointer. 

5. Next, the CRegistryMgr is connected to the CDriverlnfo pointer, and 
directed to load its contents to or from the registration database. 

6. The CRegistryMgr loads all general driver information and fills out the 
drivers XMC_DRIVERJNFO data structure, stored in the CDriverlnfo object. 

7. If the driver has any streams information stored, the CRegistryMgr loads 
the stream information and fills out an XMC_STREAM_INFO structure. The structure is 
then used to create a new CSimpleStream object. 
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8. When creating the stream, the CSimpleStream object first queries and calls 
the DllGetModuleType exported function and verifies that the module is in fact a stream 
component. If the module is, the CSimpleStream then queries and calls the 
DLLRegisterServer function exported by the component to register the component. 

9. After registering the component, the CSimpleStream object queries and 
calls the DllGetCLSID exported function to get the components CLSID. Using the 
CLSID, CoCreatelnstance is called to create an instance of the OLE object. 

10. Once the CSimpleStream completes, the CRegistryMgr connects a temporary 
instance of the CStreamMgr to the CDriverlnfo object pointer, and directs it to add the 
new stream. 

1 1 . The CStreamMgr directly manipulates the CDriverlnfo's stream array to 
add the new stream. When added, a new instance of the CSimpleStream object is created 
and attached to the CSimpleStream passed to the CStreamMgr. 

12. When attaching itself to the stream, the new CSimpleStream queries the 
IXMC_StreamInit interface, passed to it, for all interfaces used it bump up the reference 
counts for the component. 

After the driver administrator is done using the driver, it must release the driver by 
calling its exposed Release method. Calling this method, directs the driver to release all 
resources used. FIG. 64 displays the process of releasing the driver component. 

During the clean-up process, the following steps occur. 

1 . First, either the XMC Driver Administrator, or the XMC Motion 
Component call the final IUnknown::Release. 

2. When invoked, the lUnknown:: Release method implemented by the 
CDriverObject is called. After calling this method causes the internal OLE reference 
count to go to zero, driver calls its implementation of ICOM_Base::Uninitialize to clean 
up all resources used. 

3. First, ICOM_Base::Uninitialize directs the CDrvExtDisp to clean up any 
resources that it was using. 
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4. Next, ICOM_Base::Uninitialize directs the CDrvCoreDisp object to clean 
up any resources that it was using. 

5. Since the CDrvCoreDisp object contains instances of all manager objects, 
it begins cleaning them up by first directing the CCommandMgr to destroy any resources 

5 that it was using. Internally, the CcommandMgr destroys the CCommandDatabase and all 
of its contents, 

6. Next, the CDrvCoreDisp object implicitly destroys all other manager 
objects by calling their destructors. 

7. And as a fmal step, the ICOM_Base::Uninitialize method deletes the state 
10 handle containing a pointer to the CDriverlnfo object. When destroyed, the CDriverlnfo 

object deletes each CSimpleStream object, which in turn release their instance of the 
XMC Stream component. Upon releasing the fmal instance of the XMC Stream 
^0 component, the component dll is freed from memory. 

m 

^ After a driver is successfully installed into the XMC system and configured using 

ifi 15 the driver administrator, it is ready for use by the XMC Motion Control Component. The 
i7j component uses the driver when performing motion control operations requested from the 

L application using the component. FIG. 65 describes the component directed operations 

that can take place on the driver. 
:^ Before operating, the XMC Motion Component must query the Driver 

5 20 administrator 32 component for its driver enumeration. The enumeration returned is used 

to access all enabled drivers that are directed to perform XMC SPI operations by the 

XMC Motion Component. 

Once the driver enumeration is acquired, the Motion control component 35 can 
direct the enabled driver, or drivers, to carry out certain command operations. Command 
25 operations are standard motion control operations such as moving to a specific location in 
the system, or querying the system for the current position. FIG 65 describes the process 
of commanding the driver to carry out a certain operation. 

When commanding the driver to perform a certain operation, the following steps 

occur. 
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1 . First, the motion component directs the driver to perform the operation, 
such as moving to a position or querying the system for the current position. 

2. The XMCSPI invocation is handled by the CDriverObject who implements 
all OLE interfaces exposed by the component. 

3. The CDriverObject directs either the CDrvCoreDisp, or CDrvExtDisp 
object to perform the operation, depending on whether the operation is a core or extended 
XMCSPI. The component state handle is passed to the dispatch object when called. 

4. The dispatch object then typecasts the state handle into a CDriverlnfo 
object pointer. 

5. Next, the dispatch object connects the CCommandMgr to the CDriverlnfo 
object pointer and directs it to carry out the operation corresponding to the database index 
sent. The database index corresponds to the XMCSPI called and is used to locate the 
language database entry for that SPI call. 

6. The CCommandMgr searches the CCommandDatabase for the index and 
builds a CCommand object corresponding to the XMCSPI operation. 

7. Next, the CCommandMgr directly accesses the CDriverlnfo and passes the 
command string, built by the CCommand object, to all enabled streams. 

8. Each enabled stream sends the ASCII text to its target. For example, the 
PCBus steam sends its data to the motion control card located on the PCBus. The text file 
stream, on the other hand, sends its data to its associated text file. 

9. If directed, the CCommandMgr then queries the first readable stream for 
the results of the commands sent to it^ 

10. The CSimpleStream reads the raw response from the target and returns it to 
the CCommandMgr. 

1 1 . Once receiving the raw response, the CCommandMgr uses the CResponse 
object to parse the raw response based on the response format corresponding to the 
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XMCSPI database entry. All response parameters are returned back up the calling chain, 
and eventually end up in the hands of the original caller, the XMC Motion Component. 

The clean-up initiated by the XMC Motion Component by releasing the XMC 
Driver component is the same as that which occurs when the Driver administrator 32 
object releases the component. 

The following discussion describes the actual OLE Interfaces exposed, the 
definitions of the data structures used when passing data around, and the definitions of 
each class used internally by the driver. 

The following diagram describes all interfaces exposed by the driver specific to 
driver-component interpretability. FIG. 66 graphically displays the interfaces exposed by 
the component. 

Other than the two standard interfaces exposed, such as lUnknown and 
IClassFactory, there are three categories of interfaces exposed by the component. The 
three categories are as follows. 

COM: All interface names with the COM_ prefix, implement general 
COM functionality. For example, the ICOM_Base, IC0M_Base2, IC0M_Persist2, and 
ICOM_PersistRegDB interfaces all fall into this category. 

LNG: All interface names with the LNG_ prefix, implement general 
language driver fiinctionality. For example, the ILNG_DrvCore_Init, and the 
ILNG_DrvExt_StreamMgmt interfaces fall into this category. 

XMC: All interfaces name with the XMC_ prefix, implement XMCSPI 
(driver) functionality. 

The following sections describe the interfaces falling into both the COM and LNG 
categories. All other interfaces are XMCSPI specific and are used for the sole purpose of 
performing motion control operations. 

The following exposed methods in the ICOM_Base interface are used when 
intializing and uninitializing the component. Each of these methods call the hidden 
initialize and uninitialize interface methods implemented by all of the component's 
interfaces. 

DECLARE_INTERFACE_( ICOM_Base, lUnknown ) 

u 
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{ 

STDMETHOD ( Initialize )( THIS_ LPVOID pinitlnfo ) PURE; 
STDMETHOD ( Uninitialize )( THIS ) PURE; 

}; 

The IC0M_Base2 interface inherits from the ICOM_Base interface and adds 
several methods used to manage the internal component state handle. In addition, a 
method allows the user to translate any HRESULT returned by the component into a 
human readable text string. The following is a description of the IC0M_Base2 interface. 

DECLAREJNTERFACEJ IC0M_Base2, ICOM_Base ) 
{ 

STDMETHOD ( SetStateData )( THIS_ COM_STATEHANDLE hState ) PURE; 
STDMETHOD ( GetStateData )( THIS_ LPCOM_STATEHANDLE phState ) 

PURE; 

STDMETHOD ( GetErrorString )( THIS_ HRESULT hr, LPSTR pszErr, DWORD 
dwMax ) PURE; 

}; 

The IC0M_Persist2 interface inherits from the IPersist standard OLE interface 
and adds several methods used to query the CLSID and module type. The following is a 
description of the IC0M_Persist2 interface. 

DECLARE_INTERFACE_( ICOM_Persist2, IPersist ) 
{ 

STDMETHOD ( GetID )( THIS_ LPDWORD pdwID ) PURE; 
STDMETHOD ( GetModuleType )( THIS_ LPDWORD pdwMT ) PURE; 

}; 

The ICOM_PersistRegDB interface implements similar functionality to that 
provided by the IPersistFile standard OLE interface. Instead of saving and loading data to 
and from a file, the ICOM PersistRegDB operates on the registration database. The 
following is a description of the ICOM_PersistRegDB interface. 
DECLARE_INTERFACE J ICOM_PersistRegDB, lUnknown ) 

{ 
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STDMETHOD ( IsDirty )( THIS ) PURE; 
STDMETHOD ( Load )( THIS_ HKEY hKey ) PURE; 
STDMETHOD ( Save )( THIS_ HKEY hKey ) PURE; 
STDMETHOD ( Clear )( THIS_ HKEY hKey ) PURE; 

}; 

The ILNG_DrvCore_Init interface is used to initialize the language driver 
component. The following is a description of the ILNG_DrvCore_Init interface. 
DECLARE_INTERFACE_( ILNG_DrvCore_Init, lUnknown ) 
{ 

STDMETHOD (Create)( THIS_ LPLNG_DRIVER_INFO pDI ) PURE; 
STDMETHOD (Destroy)( THIS ) PURE; 

STDMETHOD (Setup)( THIS__ LPLNG_DRIVER_INFO pDI ) PURE; 
STDMETHOD (Stat)( THIS_ LPLNG_DRIVER_INFO pDI ) PURE; 
STDMETHOD (Register)( THIS ) PURE; 
STDMETHOD (UnRegister)( THIS ) PURE; 

STDMETHOD {IsRegistered)( THIS_ LPBOOL pbRegistered ) PURE; 
STDMETHOD (Enable)( THIS_ BOOL ffinable ) PURE; 
STDMETHOD (IsEnabled)( THIS_ LPBOOL pbEnabled ) PURE; 

}; 

The ILNG_DrvExt_StreamMgmt interface is used to perform all stream 
operations. The following is a description of the LNG_DrvExt_StreamMgmt interface. 
DECLARE_INTERFACE_( ILNG_DrvExt_StreamMgmt, lUnknown ) 

{ 

STDMETHOD (GetStreamEnumeration)( THIS_ LPENUMUNKNOWN FAR 
*ppEnumStream ) 
PURE; 

STDMETHOD (GetStreamCount)( THIS_ LPDWORD pdwCount ) PURE; 
STDMETHOD (GetStreamInit)( THIS_ XMC_STREAMID idStream, 
LPXMCSTREAMINIT FAR *ppStreamInit ) PURE; 
STDMETHOD (GetStreamInitAt)( THIS_ DWORD dwidx, 
LPXMCSTREAMINIT FAR *ppStreamInit ) PURE; 
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STDMETHOD (AddStream)( THIS_ LPXMCSTREAMINIT pStreamlnit ) PURE; 
STDMETHOD (RemoveStream)( THIS_ LPXMCSTREAMINIT pStreamlnit, 
BOOL bDestroy ) PURE; 

STDMETHOD (RemoveStream)( THIS_ XMC_STREAMID idStream, BOOL bDestroy ) 
PURE; 

STDMETHOD (Remove All Streams)( THIS_ BOOL bDestroy ) PURE; 
STDMETHOD (EnabledStreamsOnly)( THIS_ BOOL bEnabledOnly, 
LPBOOL pbOldEnabledOnly ) PURE; 



The following discusion defines all structures, enumerations, and defines used by 
the driver. 

The XMC_DRIVER_MODULETYPE enumeration defines the type of drivers 
available. Each driver must return its type when the user calls the exported 
DLLGetModuleType function, 
enum XMC_DRIVER_MODULETYPE 

{ 



XMC_ 


_DRIVER_MT = 0x4000, 


XMC 


_DRIVER_MT_AT6400 


= 0x4001, 


XMC 


DRIVERMTDMC 1 000 


= 0x4002, 


XMC 


_DRIVER_MT_DT2000 


= 0x4003, 


XMC 


DRIVER MT CUSTOM 


= 0x4004 



The XMC_DRVCORE_CMD enumeration defines an identifier for every 
command known to the XMC Driver. For example, every core Driver fianction has a 



}; 



The following are the functions exported by the driver DLL. 



XMC_DRIVER_MODULETYPE DLLGetModuleType( void ); 
LPCLSID DLLGetCLSID( void ); 

BOOL DLLRegisterServer( void ); 

BOOL DLLUnRegisterServer( void ); 



}; 




corresponding XMC_DRVCORE_CMD identifier. This index is used to look up the 
string block for the command. The definition of the enumeration is as follows. 

enum XMC_DRVCORE_CMD 
{ 

XMC_DCC_MOTION_MOVEABS, 
XMC_DCC_MOTION_KILL, 

}; 

The XMC_DRVEXT_CMD enumeration defines an identifier for every extended 
command known to the XMC Driver. Even though the identifiers exist, the driver may or 
may not implement the set of commands. For example, every extended Driver function 
has a corresponding XMC_DRVEXT_CMD identifier. This index is used to look up the 
string block for the command (if the driver implements the command). The definition of 
the enumeration is as follows. 

enum XMC_DRVEXT_CMD 

{ 

XMC_DCE_MOTION_MOVEREL, 

}; 

The LNG_PARAM_DATATYPE enumeration defines all types of data blocks that 
may be parsed from response strings returned by stream targets. 

typedef enum _LNG_PARAM_DATATYPE 

{ 

LNG_ADT_NOP, 
LNG_ADT_NOTYPE, 
LNG_ADT_NUMBER, 
LNG_ADT_STAT_STRING, 
LNG_ADT_MEM_STRING 
} LNG_PARAM_DATATYPE; 
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The LNG_PARAM_DATA structure stores all types of data that describe a 
parameter either built into a command, or parsed from a response. 

struct LNG_PARAM_DATA 

{ 

//— - Constructor & Destructor — - 



LNG_PARAM_DATA( void ); 
'-LNG_PARAM_DATA( void ); 

//-— Data — 

LNG_PARAM_DATATYPE adt; 
union 



The LNG_DRIVER_INFO structure is used when setting up and querying the 
state of the driver. 

typedef struct _LNG_DRIVER_INFO 

{ 



double df; 



LPTSTR psz; 



}; 



}; 



DWORD 



m_mt; 



LNG DRIVERID 



m_ID; 



TCHAR 



TCHAR 



TCHAR 



m_szName[ LNG_DRIVER_N AME_LEN+ 1 ]; 
m_szDescription[ LNG_DRJVER_DESC_LEN+1 ]; 
m_szHWVendor[ LNG_DRIVER_NAME_LEN+1 



]; 
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} LNG_DRIVER_INFO; 

Each XMC Driver is responsible for managing all streams used. In order to 
manage each stream over time in a persistent manner each driver and stream module 
implement the persistent functionality exposed through the ICOM_PersistRegDB 
interface. When the driver's implementation of ICOM_PersistRegDB::Save is called, the 
data is saved to the registry in the following order. 

XMCDriverAdminObject. 1 00 
I — Drivers 

I — dwCount = <# of drivers> 

I — XMCDrv_0 

I I— - CLSID = {clsid} 

I I — dwFlags = <driver flags> 

I I— dwID = <driver ID> 

I dwModuleType = XMC_DRIVER_MT_xxx 

I |- — szDescription = <user desc of the driver> 
I |- — Streams 

I |- — Count = <# of streams> 

I I-— XMCStrm_0 

I I I — CLSID = {clsid} 

I I I — dwID = <strm id> 

I I I — dwModuleType = XMC_STREAM_MT_xxx 

I I I — <stream specific values> 

I I— - XMCStrm_<n> 

I — XMCDrv_<n> 

It should be clear from the foregoing that the present invention may be embodied 
in other specific forms without departing from the essential characteristics thereof The 




present embodiments are therefore to be considered in all respects as illustrative and not 
restrictive, the scope of the invention being indicated by the appended claims rather than 
by the foregoing description; all changes which come within the meaning and range of 
equivalency of the claims are therefore intended to be embraced therein. 
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